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NATIONAL FOREWORD 

This Indian Standard which is identical with ISO 8650 : 1988 'Information processing systems — 
Open systems interconnection — Protocol specification for the association control service 
element', issued by the International Organization for Standardization ( ISO ), was adopted by 
the Bureau of Indian Standards on the recommendation of the Computer Systems and Inter* 
connection Sectional Committee and approval of the Electronics and Telecommunication 
Division Council. 

In the adopted standard certain terminology and conventions are not identical to those used 
in the Indian Standards. Attention is particularly drawn to the following: 

Wherever the words 'International Standard' appear referring to this standard, they should 
be read as 'Indian Standard', 

In this Indian Standard, the following international standards are referred to. Read in their 
respective place the following: 

International Standard Indian Standard 

ISO 7498 Information processing systems — Open IS 12373 ( Part 1 ) : 1987 Basic reference 
systems interconnection — Basic reference model of open systems interconnection 

model for information processing systems : 

Part 1 ( Identical ) 

ISO 7498-3 Information processing systems— 12373 ( Part 3 ) : 1993 Basic reference 
Open systems interconnection — Basic reference model of open systems interconnection 

model — Part 3 : Naming and addressing for information processing systems: Part 

3 Naming and addressing ( Identical ) 

ISO 8649 Information processing systems — Open IS 13615 : 1993 Service definition for the 
systems interconnection — Service definition association control service element in 

for the association control service element open systems interconnection for infor- 

mation processing systems ( Identical ) 

ISO 8822 Information processing systems-Open DOC LTD 36 ( 1636 ) P1 Connection ori- 
systems interconnection — Connection oriented ented presentation Service definition 

presentation service definition in open systems interconnection for 

information processing systems ( Under 
preparation ) ( Identical ) 

The technical committee responsible for the preparation of this Indian Standard has reviewed 
the provisions of the following ISO standards and has decided that it is acceptable for use in 
conjunction with this standard: 

ISO/TR 8509 : 1987 Information processing systems — Open systems interconnection — 

Service conventions 

ISO 8824 : 1987 Information processing systems — Open systems interconnection — 

Specification of Abstract Syntax Notation one ( ASN. 1 ) 

ISO 8825 : 1987 Information processing systems — Open systems interconnection — 

Specification of basic encoding rules for Abstract Syntax Notation 
one ( ASN 1 ) 

ISO 8326 Information processing systems — Open systems interconnection — 

Basic connection oriented session service definition 

ISO 8327 Information processing systems — Open systems interconnection — 

Basic connection oriented session protocal specification 

CCITT Recommendation X.410: Message handling systems : Remote operations and reliable 
transfer server ( 1984 ) 

Only the English language text in the International Standard has been retained while adopting 
it in this standard. 
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.TECHNICAL CORRIGENDUM 1 



TMi technical corrigendum it applied to ISO 8860. Insertions are contained between « and » and are in italics : a This is an example of 
t*xt» Deleted text is marked by strike-thru. Editing instructions are within { and }, are capitalized, and are in italics. 



9 Structure and encoding of ACSE APDUs 

\IN PARAGRAPH 9.1 INSERT THE FOLLOWING ASN. I PRODUCTION FOLLOWING THE BEGIN OPERATOR:) 

IMPORTS Nana, RelativeDistinguishedName 
FROM InformationFramework 

{ joint-iso-ccitt ds(5) modules(l) 
inf ormationFraitevork( 1 ) 

> 

, —The data types Name and RelativeDistinguishedName are imported from ISO 9594-2. 

i 

I 

{ALSO, IN PARAGRAPH 9. 1. REPLACE THE EXISTING A SN. 1 FORAP-TITLE. AS- QUALIFIER, AND AE-TITLE WITH THE FOLLOWING 
| ASN. 1 PRODUCTIONS AND COMMENTS:} 

< AP-title ::• CHOICE { AP-title-forml , AP-title-form2 } 

AE-qualif ier ::■ CHOICE { AE-qualif ier-forml, AE-qualif ier-form2 } 

—When both AP-title and AE-qualifier data values are present in an 
- AARQ or AARE APDU, both must have the same form to allow the 
-construction of an AE-title as discussed in ISO 9834-6. 

AP-title-forml ::■ Name 

-The value assigned to AP-title-forml is The Directory Name of an 
—application-process title. 

AE-qualifier- forml ::• RelativeDistinguishedName 

-The value assigned to AE-qualifier-forml is the relative 
-distinguished name of a particular application-entity of the 
-application-process identified by AP-title-forml. 

AP-title-form2 ::■ OBJECT IDENTIFIER 
AE-qualif ier-form2 ::- INTEGER 



-As defined in ISO 7498-3 , an application-entity title is composed 
-of an application-ptocess title and an application-entity 
-qualifier. The ACSE protocol provides for the transfer of an 
-application-entity title value by the transfer of its component 
-values. However, the following data type is provided for 
-International Standards that reference a single syntactic structure 
-for, AS titles. 



AE-title ::■ CHOICE { AE-title-forml, AE-title-form2 } 
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AE-title-forml ::■ Name 

-For access to The Directory (ISO 9594), an AB title has 
-AE-title-f orml . This value can be constructed from 
-AP-title-forml and AE-qualif ier-forml values contained in an 
-AARQ or AARE APDU. A discussion of forming an AB-title-formi 
-from AP-title-forml and AE-qualifier-forml may be found in 
-ISO 9834-6. 



AE-title-form2 ::- OBJECT IDENTIFIER 

-A discussion of forming an AE-title-form2 from AP-title-form2 
-and AE-qualif ier-form2 may be found in ISO 9834-6. 
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10 Conformance 

{CHANGE 10.0.3 TO READ:} 

10.0.3 The X.410-1 984 mode exists to allow compatibility 
with message handling systems implementing the protocol 
specified in CCITT Recommendation X.410-1 984. 

{CHANGE SUB-ITEM 2) OF ITEM c) OF 10.1 TOREAD:} 

2) the X.410-1 984 mode of ACSE protocol to support a 
message handling system; or 

10.1 Statement requirements 

{NO CHANGE} 

10.2 Static requirements 

{NO CHANGE} 



10.3 Dynamic requirements 

10.3.1 Normal mode 

{NUMBER THE EXISTING PARAGRAPH AS 10.3. 1. 1. ADD THE 
FOLLOWING TEXT AS PARAGRAPH 10.3. 1.2:} 

10.3.1 .2 The requesting AE may choose to send either form 1 
or form2 for AP title and AE qualifier. The accepting AE may 
respond with either form. Thus, both the requesting and 
responding AE must be capable of receiving both forms. 

10.3.2 X.410-1 984 mode 

{NO CHANGE} 
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Indian Standard 

PROTOCOL SPECIFICATION FOR THE ASSOCIATION 

CONTROL SERVICE ELEMENT IN OPEN SYSTEMS 

INTERCONNECTION FOR INFORMATION 

PROCESSING SYSTEMS 



Introduction 

0.1 This International Standard is one of a set of Internation- 
al Standards produced to facilitate the interconnection of in- 
formation processing systems. It is related to other Interna- 
tional Standards in \\ »e set as defined by the Reference Model 
for Open Systems Interconnection (ISO 7498). The 
Reference Model subdivides the area of standardization for 
interconnection into a series of layers of specification, each 
of manageable size. 

0.2 The goal of Open Systems Interconnection is to allow, 
with a minimum of technical agreement outside the intercon- 
nection standards, the interconnection of information 
processing systems: 

— from different manufacturers; 
— under different managements; 
— of different levels of complexity; and 
— of different technologies. 

0.3 This International Standard specifies the protocol for the 
application-service-element for application-association con- 
trol: the Association Control Service Element (ACSE). The 
ACSE provides services for establishing and releasing ap- 
plication-associations. These services are intended to be ap- 
plicable to a wide range of application-process communica- 
tion requirements. 

0.4 This International Standard includes an annex that 
describes the protocol machine of ACSE in terms of a state 
table. This protocol machine is referred to as the Associa- 
tionrControl Protocol Machine IACPM). 

0.5 The protocol defined in this International Standard is also 
governed by the use of the presentation-service (ISO 8822) 
and the session-service (ISO 8326). 

0.6 Quality of Services (QOS) is a parameter of the A-AS- 
SOCIATE service. Work is still in progress to provide an in- 
tegrated treatment of QOS across all of the layers of the OSI 
Reference Model and to ensure that the individual treatments 
in each layer service satisfy overall QOS objectives in a con- 
sistent manner. As a consequence, an addendum may be 



added to this International Standard at a later time which 
reflects further QOS developments and integration. 



1 Scope and field of application 

The procedures defined in this International Standard are ap- 
plicable to instances of communication between systems 
which wish to interconnect in an open systems interconnec- 
tion environment. 

This International Standard specifies: 

a) procedures for the transfer of information relating to 
application-association control between application-en- 
tities; and 

b) the abstract syntax for the representation of the ACSE 
APDUs. 

The ACSE procedures are defined in terms of: 

a) the interactions between peer ACSE protocol 
machines through the use of presentation-services; and 

b) the interaction between an ACSE protocol machine 
and its service-user. 

This International Standard also specifies conformance re- 
quirements for systems implementing these procedures, it 
does not contain tests which can be used to demonstrate 
conformance. 



2 References 

ISO 7498, Information processing systems - Open Systems 
Interconnection - Basic Reference Model. 

ISO 7498-3, Information processing systems - Open Sys- 
tems Interconnection - Basic Reference Model • Parr 3: 
Naming and Addressing. 1 



1 At present at the stage of draft, publication anticipated in due course. 



IS 13706 : 1903 
ISO 8650 : 1988 



ISO 8326, Information processing systems - Open Systems 
Interconrr rtfon - Basic connection oriented session service 
definition. 

ISO 8327, Information processing systems - Open Systems 
Interconnection - Basic connection oriented session protocol 
specification. 

ISO/TR 8509, Information processing systems - Open Sys- 
tems Interconnection - Service conventions. 

ISO 8649, Information processing systems - Open Systems 
interconnection - Service definition for the Association Con- 
trol Service Element. . 

ISO 8822, Information processing systems - Open Systems 
Interconnection - Connection oriented presentation service 
definition. 

ISO 8824, In formation processing systems - Open Systems 
Interconnection - Specification of Abstract Syntax Notation 
One fASN. 11 

ISO 8825, Information processing systems - Open Systems 
Interconnection - Specification of Basic Encoding Rules for 
Abstract Notation One (ASN. 1). 

CCITT Recommendation X.410: Message Handling Sys- 
tems: Remote Operations and Reliable Transfer Server 
(1984). 



3 Definitions 

3.1 Reference Model definitions 

This International Standard is based on the concepts 
developed in ISO 7498 and makes use of the following terms 
defined in it: 

a) Application Layer; 

b) application-process; 

c) application-entity; 

d) application-service-element; 

e) application-protocol-data-unit; 

f) application-protocol-control-information; 

g) presentation-service; 

h) presentation-connection; 
i) session-service; 



j) session-protocol; and 
k) session-connection. 

3.2 Naming and addressing definitions 

This International Standard makes use of the following terms 
defined in ISO 7498-3: 

a) application-p^oce$s t/tle; 

b) application-entity qualifier; 

c) application-entity title 1 ; 

d) application-process invocation-identifier; 

e) application-entity invocation-identifier; and 

f) presentation address. 

3.3 Service conventions definitions 

This International Standard makes use of the following terms 
defined in ISO/TR 8509: 

a) service-provider; 

b) service-user; 

c) confirmed service; 

d) non-confirmed service; 

e) provider-initiated service; 

f) primitive; 

g) request (primitive); 
h) indication (primitive); 

i) -response (primitive); and 
j) confirm (primitive). 

3.4 Presentation service definitions 

This International Standard makes use of the following term! 
defined in l$0 8822: 

a) abstract syntax; 

b) abstract syntax name; 

c) default context; 



1 As defined in ISO 7498-3, an application-entity title is composed of an application-process title and an application-entity qualifier. The 
ACSE protocol provides for the transfer of an application-entity title value by the transfer of its component values. 
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d) defined context set; 

e) functions! unit [presentation); 

f) normal mode [presentation]; 

g) presentation context; 

h) presentation data vslue; and 
i) X.41 0-1 984 mode [presentation]. 

3.5 ACSE service definitions 

This International Standard makes use of the following terms 
defined in ISO 8649: 

a) application-association; association; 

b) application context; 

c) Association Control Service Element; 

d) ACSE service-user; 

e) ACSE service-provider; 

f) requestor; 

g) acceptor; 

h) association-initiator; 
i) association-responder; 
j) normal mode; 
k) X.41 0-1 984 mode; and 
I) disrupt. 

3.6 Association Control protocol specification 
definitions 

The following terms are introduced in this International Stan- 
dard. 

3.6.1 Association Control Protocol Machine: The protocol 
machine for the Association Control Service Element 
specified in this International Standard. 

3.6.2 requesting Association Control Protocol Machine: The 

Association Control Protocol Machine whose service-user is 
the requestor of a particular Association Control Service Ele- - 
ment service. 

3.6.3 accepting Association Control Protocol Machine: The 

Association Control Protocol Machine whose service-user is 
the acceptor for a particular Association Control Service Ele- 
ment service. 



4 Symbols and abbreviations 

4.1 Data units 

APDU application-protocol-data-unit 

4.2 Types of application-protocol-data-units 

The following abbreviations have been given to the applica- 
tion-protocol-data-units defined in this International Stan- 
dard. 

AARQ A-ASSOCIATE-REQUEST APDU 

AARE A-ASSOCIATE-RESPONSE APDU 

RLRQ A-RELEASE-REQUEST APDU 

RLRE A-RELEASE-RESPONSE APDU 

ABRT A-ABORT APDU 

4.3 Other abbreviations 

The following abbreviations are used in this International 
Standard. 



ACPM 


Association Control Protocol Machine 


ACSE 


Association Control Service Element 


AE 


application-entity 


AP 


application-process 


APCI 


application-protocol-control-information 


ASE 


application-service-element 


ASN.1 


Abstract Syntax Notation One 


OSI 


Open Systems Interconnection 


DOS 


quality of service 


6 Conventions 



5.1 This International Standard employs a tabular presenta- 
tion of its APDU fields. In clause 7, tables are presented for 
each ACSE APDU. Each field is summarized using the fol- 
lowing notation: 

M presence is mandatory 

presence is ACPM option 

U presence is ACSE service-user option 

req source is related request primitive 

ind sink is relsted indication primitive 

rsp source is related response primitive 

cnf sink is related confirm primitive 

sp source or sink is the ACPM 

5.2 The structure of each ACSE APDU is specified in clause 
9 using the abstract syntax notation of ASN.1 (ISO 8824). 
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6 Overview of the protocol 

6.1 Service provision 

The protocol specified in this International Standard provides 
the services defined in ISO 8649. These services are listed 
in table 1 . For a particular association, the ACSE services 
operate either in the normal mode or in the X.410-1984 
mode. The mode of operation is determined by the Mode 
parameter on the A-ASSOCIATE request primitive. 



Table 1 - Service summary 



Service 


Type 


A-ASSOCIATE 
A-RELEASE 
A-ABORT 
A-P-ABORT 


Confirmed 
Confirmed 
Non-confirmed 
Provider-initiated 



6.2 Use of the presentation-service 

6.2.1 ACSE's use of the presentation-service is determined 
by ACSE's mode of operation for an association as specified 
below. 

a) ACSE normal mode: The ACPM uses the normal 
mode of the presentation- service (ISO 8822). The 
ACPM uses the presentation-service Kernel functional 
unit to exchange its APCI and, optionally, ACSE service- 
user information (i.e., ACSE APOUs) with its peer. The 
use of additional presentation-service functional units is 
an ACSE service-user choice. This choice does not affect 
the operation of the ACPM. 

b) ACSE X.410-1984 mode: The ACPM uses the 
X.41 0-1 984 mode of the presentation-service. Only the 
Kernel functional unit is available when using the presen- 
tation-service X.410-1984 mode. In this mode, the 
ACPM does not exchange its own APCI with its peer. It 
simply passes through information supplied to it by the 
ACSE service-user or by the presentation-service. 

6.2.2 This International Standard assumes that the ACPM is 
the sole user of the P-CONNECT, P-RELEASE, P-U-ABORT, 
and P-P-ABORT services. The ACSE neither uses nor con- 
strains the use of any other presentation service. 

6.2.3 When supported by version 1 of the session-protocol 
(ISO 8327), the presentation-sen/ice is subject to length 
restrictions for its user-data parameters. This International 
Standard assumes that a local mechanism detects violations 
of these constraints and makes the ACSE service user aware 
oHhem. An encoding optimization is specified for A-ABORT 
to mitigate this problem (see 7.3.3.1 ). 

6.3 Relationship to the session-service 

6.3.1 The session functional units required for the session- 
connection that supports the presentation-connection (that 
in turn supports the association) are determined by the A- 
ASSOCIATE service requestor and acceptor. They ac- 



complish this using the Session Requirements parameter on 
the A-ASSOCIATE primitives. The session functional units 
are described in ISO 8326. 

6.3.2 The rules of the session-service affect the operation 
of the ACPM and its service-user. The ACSE service-user 
must be aware of these constraints. This International Stan- 
dard assumes that a local mechanism enforces them. Some 
examples of session-service constraints that affect the 
ACSE service-user are: 

a) the availability of negotiated release; and 

b) the possibility of release collisions. 
6.4 Model 

6.4.1 The Association control Protocol Machine (ACPM) is 
modeled as a finite state machine whose specification is 
given in this International Standard. The ACPM communi- 
cates with its service-user by means of the ACSE service 
primitives defined in ISO 8649. The ACPM communicates 
with its presentation service-provider by means of the 
presentation services defined in ISO 8822. 

6.4.2 The ACPM is driven by the receipt of input events from 
its ACSE service-user and from its presentation service- 
provider for the underlying presentation-connection that sup- 
ports the association. The input events from the ACSE ser- 
vice-user are ACSE request and .esponse primitives. The 
input events from its presentation service-provider are 
presentation indication and confirm primitives. 

6.4.3 The ACPM responds to input events by issuing output 
events to its presentation service-provider and to its ACSE 
service-user. The output events to its presentation service- 
provider are presentation request and response primitives. 
The output events to its ACSE service-user are ACSE indica- 
tion and confirm primitives. 

6.4.4 The receipt of an input event, the generation of de- 
pendent actions, and the resultant output event are con- 
sidered to be an indivisible action. 

6.4.5 During the establishment of an association between 
two AEs, the existence of invocations of both the request- 
ing and responding AEs is presumed. How they are created 
is outside of the scope of this International Standard. 

6.4.6 A new invocation of an ACPM is employed upon the 
receipt of an A-ASSOCIATE request primitive or a P-CON- 
NECT indication primitive. Each such invocation controls ex- 
actly one association. 

NOTE — Eacn asiociation may be identified in an end system by 
a local mechanism so that the ACSE service-user and the ACPM 
can refer tp the association. 

6.4.7 The ACPM is modeled to operate In either one of two 
modes for a given association: the normal mode; and the 
X.41 0-1 984 mode as specified below. 

a) When operating in the normal mode, an ACPM com- 
municates with its peer ACPM in support of an associa- 
tion by transferring ACSE application protocol data units 
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(APDUs) defined in clause 9. 1 An ACSE APDU is trans- 
ferred as a presentation data value in the User Data 
parameter of the presentation primitive used on the un- 
derlying presentation- connection. 

b) When operating in the X.410-1 984 mode, an ACPM 
does not transfer ACSE APDUs with its peer. In this situa- 
tion, the sending and receiving of presentation primitives 
are in themselves significant protocol events. 



7 Elements of procedure 

The ACSE protocol consists of the following procedures: 

a) association establishment; 

b) normal release of an association; and 

c) abnormal release of an association. 

In this clause, a summary of each of these elements of pro- 
cedure is presented. This consists of a summary of the 
relevant APDUs, and a high-level overview of the relation- 



ship between the ACSE services, the APDUs involved, and 
the presentation service that is used. Clause 8 describes 
how the parameters of the presentation primitives are used. 
In clause 9, a detailed specification of the ACSE APDUs is 
given using the notation of ASN.1 (ISO 8824). Annex A 
presents the state table for the ACPM. 

7.1 Association establishment 

7.1.1 Purpose 

The association establishment procedure is used to establish 
an association between two AEs. It supports the A-AS- 
SOCIATE service. 

7.1.2 APDUs used 

The association establishment procedure uses the A-AS- 
SOCIATE-REQUEST (AARQ) and the A-ASSOCIATE- 
RESPONSE (AARE) APDUs. The fields of the AARQ APDU 
are listed in table 2. The fields of the AARE APDU are listed 
in table 3. 



Table 2 - AARQ APDU fields 



Field name 


Presence 


Source 


Sink 


Protocol Version 





sp 


sp 


Application Context Name 


M 


req 


ind 


Calling AP Title 


U 


req 


ind 


Calling AE Qualifier 


U 


req 


ind 


Calling AP Invocation-identifier 


U 


req 


ind 


Calling AE Invocation-identifier 


U 


req 


ind 


Called AP Title 


U 


req 


ind 


Called AE Qualifier 


U 


req 


ind 


Called AP Invocation-identifier 


U 


req 


ind 


Called AE Invocation-identifier 


U 


req 


ind 


Implementation Information 





sp 


sp 


User Information 


U 


req 


ind 



Table 3 - AARE APDU fields 



Fieldname 


Presence 


Source 


Sink 


Protocol Version 





sp 


sp 


Application Context Name 


M 


rsp 


enf 


Responding AP Title 


U 


rsp 


enf 


Responding AE Qualifier 


U 


rsp 


enf 


Responding AP Invocation-identifier 


U 


rsp 


enf 


Responding AE Invocation-identifier 


U 


rsp 


enf 


Result 


M 


fsp/sp 


enf 


Result Source - Diagnostic 


M 


rsp/sp 


enf 


Implementation Information 





sp 


sp 


JJssr Information 


U 


2£ 


enf 



TNs is trus with one exception. If the association is supported by version 1 of the session-protocol (ISO 8327), the requesting ACPM 
does not pass ACSE APCI as user data on a P4J-ABORT request primitive. The absence of ACSE APCI in this situation does not imply 
that the association Is operating in the X.410-1984 mods (see 6.4.6 and 7.3.3.1). 
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7.1 .3 Association establishment procedure 

This procedure is driven by the following events: 

a) an A-ASSOCIATE request primitive from the reques- 
tor; 

b) an AARQ APDU as user data on a P-CONNECT indica- 
tion primitive; 

c) an A-ASSOCIATE response primitive from the ac- 
ceptor; and 

d) a P-CONNECT confirm primitive (that may or may not 
contain an A ARE APDU). 

7.1.3.1 A-ASSOCIATE request primitive 

7.1 .3.1 .1 The requesting ACPM forms an AARQ APDU from 
parameter values of the A-ASSOCIATE request primitive and 
optionally, the Protocol Version and implementation informa- 
tion. It issues a P-CONNECT request primitive also using in- 
formation from the A-ASSOCIATE request primitive. The 
User Data parameter of the P-CONNECT request primitive 
contains the AARQ APDU. 

7.1.3.1.2 The requesting ACPM waits for a primitive from 
the presentation service-provider and does not accept any 
other primitive from the requestor other than an A-ABORT 
reauest primitive. 

7.1.3.2 AARQ APDU 

7.1.3.2.1 The accepting ACPM receives an AARQ APDU 
from its peer as user data on a P-CONNECT indication primi- 
tive. 

7.1.3.2.2 The ACPM determines if the AARQ APDU is ac- 
ceptable based on the rules for extensibility (see 7.4). If the 
AARQ APDU is not acceptable, a protocol error results (see 
7.3.3.4). The association establishment procedure is dis- 
rupted. An A-ASSOCIATE indication primitive is not issued. 
The association is not established. 

7.1 .3.2.3 The ACPM next inspects the value of the Protocol 
Version field 1 of the AARQ APDU. If the ACPM does not 
support a common protocol version, it forms an A ARE APDU 
with the following assigned fields: 

a) Protocol Version field (optional) with the value that in- 
dicates the protocol version(s) that it could support (see 
7.1.5.1); 

b) Application Context Name field with the same value 
as on the AARQ APDU; 

c) Result field with the value "rejected(permanent)"; and 



d) Result Source - Diagnostic field with the values 
"ACSE service-provider" and "no common ACSE ver- 
sion." 

In this case, the ACPM sends the AARE APDU as user data 
on a P-CONNECT response primitive with a Result parameter 
that has the value "user rejection." The ACPM does not 
issue an A-ASSOCIATE indication primitive. The associa- 
tion is not established. 

7.1.3.2.4 If the P-CONNECT indication primitive and its 
AARQ APDU are acceptable, the ACPM issues an A-AS- 
SOCIATE indication primitive to the acceptor. The A-AS- 
SOCIATE indication primitive parameters are derived from 
the AARQ APDU and the P-CONNECT indication primitive. 
The ACPM waits for a primitive from the acceptor. 

7.1 .3.3 ASSOCIATE response primitive 

7.1.3.3.1 When the accepting ACPM receives the A-AS- 
SOCIATE response primitive, the Result parameter specifies 
whether the service-user has accepted or rejected the as- 
sociation. The ACPM forms an AARE APDU using the A-AS- 
SOCIATE response primitive parameters. The ACPM sets 
the Result Source - Diagnostic field to "ACSE service-user" 
and the value derived from the Diagnostic parameter of the 
response primitive. The AARE APDU is sent as the User 
Data parameter on the P-CONNECT response primitive. 

7.1 .3.3.2 If the acceptor accepted the association request, 
the Result parameter on the related P-CONNECT response 
primitive specifies "acceptance", and the Result field of the 
outgoing AARE APDU specifies "accepted." The association 
is established. 

7.1.3.3.3 If the acceptor rejected the association request, 
the Result parameter on the related P-CONNECT response 
primitive specifies "user-rejection", and the Result field of 
the AARE APDU contains the appropriate rejection value. 
The association is not established. 

7.1.3.4 P-CONNECT confirm primitive 

7.1.3.4.1 The requesting ACPM receives a P-CONNECT 
confirm primitive. The following situations are possible: 

a) the association has been accepted; 

b) the accepting ACPM or the acceptor has rejected the 
association; or 

c) the presentation service-provider has rejected the re- 
lated presentation connection. 

7.1 .3.4.2 If the association was accepted, the P-CONNECT 
confirm primitive Result parameter specifies "acceptance." 
The User Data parameter contains an AARE APDU. The 
Result field of the AARE APDU specifies "accepted." The 
requesting ACPM issues an A-ASSOCIATE confirm primitive 



1 If the Protocol Version field is not present In the AARQ ATOU, version 1 is assumed. 
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:o the requestor derived from parameters from the P-CON- 
slECT confirm primitive and the AARE APDU. The A-AS- 
SOCIATE confirm primitive Result parameter specifies "ac- 
;epted." The association is established. 

M .3.4.3 If the association was rejected by either the ac- 
apting ACPM or by the acceptor, the related P-CONNECT 
confirm primitive Result parameter specifies "user-rejec- 
ion." The User Data parameter contains an AARE APDU. 

M .3.4.4 The requesting ACPM issues an A-ASSOCIATE 
x>nf irm primitive to the requestor derived from parameters 
rom the P-CONNECT confirm primitive and the AARE 
*PDU. The A-ASSOCIATE confirm primitive Result 
)arameter indicates "rejected (transient)" or "rejected(per- 
nanent)." The Result Source parameter indicates "ACSE 
service-user" or "ACSE service-provider." The association 
s not established. 

7.1 .3.4.5 If the presentation-connection was rejected by the 
>resentation service-provider, the P-CONNECT confirm 
ximitive Result parameter specifies "provider-rejection." In 
this situation, the User Data field is not used. The request - 
ng ACPM issues an A-ASSOCIATE confirm primitive with 
ihe Result parameter indicating "rejected(permanent)." The 
Result Source parameter indicates "presentation service- 
provider." The association is not established. 

7.1 .4 Use of the AARQ APDU fields 

The AARQ APDU fields are used by the requesting and ac- 
cepting ACPMs as specified below. 

7.1.4.1 Protocol Version 

For the requesting ACPM: The value assigned to this field is 
determined within the implementation of the ACPM. It is a 1 t 
string where each bit that is set to one indicates the version 
of ACSE protocol that this ACPM supports. Bit represents 
version 1 ; bit 1 represents version 2; etc. Multiple bits may 
be set indicating support of multiple versions. No trailing bits 
higher than the highest version of this International Standard 
that the requesting ACPM supports are included. That is, the 
last bit of the string is set to one. 

For the accepting ACPM: The ACPM ignores trailing bits of 
this field that are higher than the one indicating the latest ver- 
sion of this International Standard that it supports. 

7.1 .4.2 Application Context Name 

For the requesting' ACPM: This value is determined by the 
value of the Application Context Name parameter of the A- 
ASSOCIATE request primitive. 



For the accepting ACPM: This value is used to determine the 
value of the Application Context Name parameter of the A- 
ASSOOATE indication primitive, if issued. 

7.1.4.3 Calling AP Title 

For the requesting ACPM: This value is determined by the 
value of the Calling AP Title parameter of the A-ASSOCIATE 
request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Calling AP Title parameter of the A-ASSOCIATE 
indication primitive, if issued. 

7.1 .4.4 Calling AE Qualifier 

For the requesting ACPM: This value is determined by the 
value of the Calling AE Qualifier parameter of the A-AS- 
SOCIATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Calling AE Qualifier parameter of the A-AS- 
SOCIATE indication primitive, if issued. 

7.1 .4.5 Calling AP Invocation-identifier 

For the requesting ACPM: This value is determined by the 
value of the Calling AP Invocation-identifier parameter of the 
A-ASSOCIATE request primitive. 

For the accepting ACPM: This value is used to derive the 
value of the Calling AP Invocation-identifier parameter of the 
A-ASSOCIATE indication primitive, if issued. 

7.1 .4.6 Calling AE Invocation-identifier 

For the requesting ACPM: This value is determined by the 
value of the Calling AE Invocation-identifier parameter of the 
A-ASSOCIATE request primitive. 

For the accepting ACPM: This value is used to derive the 
value of the Calling AE Invocation-identifier parameter of the 
A-ASSOCIATE indication primitive, if issued. 

7.1.4.7 Called AP Title 

For the requesting ACPM: This value is determined by the 
value of the Called AP Title parameter of the A-ASSOCIATE 
request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Called AP Title parameter of the A-ASSOCIATE 
indication primitive, if issued. 



The presentation-service (ISO 8822) currently does not define a Diagnostic parameter on the P-CONNECT response. However, work is 
still In progress to provide an integrated treatment of the "result" related parameters across all layers of the OSI Reference Model. As 
a consequence, an addendum may be added to this Internstional Standard at a later time that reflects further developments and 
integration. 
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7. 1 .4.8 Called AE Qualifier 

For the requesting AtPM: This value is determined by the 
value of the Called AE Qualifier parameter of the A-AS- 
SOCIATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Called AE Qualifier parameter of the AS- 
SOCIATE indication primitive, if issued. 

7.1 .4.9 Called AP Invocation-identifier 

For the requesting ACPM: This value is determined by the 
value of the Called AP Invocation-identifier parameter of the 
A-ASSOCIATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Called AP Invocation-identifier parameter of the 
A-ASSOCIATE indication primitive, if issued. 

7.1.4.10 Called AE Invocation-identifier 

For the requesting ACPM: This value is determined by the 
value of the Called AE Invocation-identifier parameter of the 
A-ASSOCIATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Called AE Invocation-identifier parameter of the 
A-ASSOCIATE indication primitive, if issued. 

7.1.4.11 Implementation Information 

For the requesting ACPM: The value assigned to this field is 
determined within the implementation of the ACPM. It con- 
tains information specific to the individual implementation of 
that ACPM. It is not used in negotiation. 

For the accepting ACPM: This field does not affect the opera- 
tion of the ACPM. Any use depends on a common under- 
standing between the requesting and accepting ACPMs. 

7.1.4.12 User Information 

For the requesting ACPM: This value is determined by the 
value of the User Information parameter of the A-AS- 
SOCIATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the User Information parameter of the A-AS- 
SOCIATE indication primitive, if issued. 

7.1 .6 Use of the AARE APDU fields 

The AARE APDU fields are used by the accepting and re- 
questing ACPMs as specified below. 

7.1.8.1 Protocol Version 

For the accepting ACPM: The value of this field assigned by 
the ACPM depends on whether the association request is ac- 
cepted or rejected by the ACPM and the acceptor, a$ 
specified below. 



a) If the association is accepted, the value assigned by 
the ACPM is a variable length bit string that indicates the 
protocol version selected by the ACPM from those 
proposed in the AARQ APDU. Only the bit indicating the 
version selected is set to one. That bit is the last bit in 
the string. 

b) If the association is rejected, the value assigned by the 
ACPM is a variable length bit string that indicates the 
protocol version(s) of this International Standard that 
could be supported by the ACPM. 

For the requesting ACPM: The use of the value in this field 
depends on whether the association request is accepted or 
rejected. 

a) If the association is accepted, this value defines the 
protocol version of this International Standard to be used 
for this association. 

b) If the association is rejected, the use of this value is a 
local option. 

7.1.5.2 Application Context Name 

For the accepting ACPM: This value is determined by the 
value of the Application Context Name parameter of the A- 
ASSOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Application Context Name parameter of the 
A-ASSOCIATE confirm primitive. 

7.1 .5.3 Responding AP Title 

For the accepting ACPM: This value is determined by the 
value of the Responding AP Title parameter of the A-AS- 
SOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Responding AP Title parameter of the A-AS- 
SOCIATE confirm primitive, if issued. 

7.1 .5.4 Responding AE Qualifier 

For the accepting ACPM: This value is determined by the 
value of the Responding AE Qualifier parameter of the A-AS- 
SOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Responding AE Qualifier parameter of the A- 
ASSOCIATE confirm primitive, if issued. 

7.1.5.6 Responding AP Invocation-identifier 

For the accepting ACPM: This value is determined by the 
value of the Responding AP Invocation-identifier parameter 
of the A-ASSOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Responding AP Invocation-identifier 
parameter of the A-ASSOCIATE confirm primitive, if issued. 
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7.1.6.6 Respor&ng AE Invocation-identifier 

For the accepting ACPM: This value is determined by the 
value of the Responding AE Invocation-identifier parameter 
of the A-ASSOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Responding AE Invocation-identifier 
parameter of the A-ASSOCIATE confirm primitive, if issued. 

7.1.5.7 Result 

For the accepting ACPM: The value is determined by the 
ACPM or by the acceptor as specified below. 

a) If the AARQ APDU is rejected by the ACPM (i.e., an 
A- ASSOCIATE indication primitive is not issued to the ac- 
ceptor), the value of "rejected(permanent)" or 
"rejected(transient)" is assigned by the ACPM. 

b) Otherwise, the value is determined by the Result 
parameter of the A- ASSOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Result parameter of the A-ASSOCIATE con- 
firm primitive. 

7.1 .5.8 Result Source - Diagnostic 

This field contains both the Result Source value and the Diag- 
nostic value. 

7.1.5.8.1 Result Source value 

For the accepting ACPM: This value is assigned by the ACPM 
as specified below. 

a) If the AARQ APDU is rejected by the ACPM (i.e., an 
A-ASSOCIATE indication primitive is not issued to the ac- 
ceptor), it assigns the value "ACSE service-provider." 

b) Otherwise, the ACPM assigns the value "ACSE ser- 
vice-user." 

For the requesting ACPM: This value is used to determine 
the value of the Result Source parameter of the A-AS- 
SOCIATE confirm primitive. 

7.1.5.8.2 Diagnostic value 

For the accepting ACPM: This value is determined by the 
ACPM or by the acceptor as specified below. 

a) If the AARQ APDU is rejected by the ACPM (i.e., an 
A* ASSOCIATE indication primitive is not issued to the ac- 
ceptor), the appropriate value is assigned by the ACPM. 

b) Otherwise, the value is determined by the value of the 
Diagnostic parameter of the A-ASSOCIATE response 
primitive. If the Diagnostic parameter \s not included on 



the response primitive, the ACPM assigns the value of 
"null." 

For the requesting ACPM: This value is used to determine 
the value of the Diagnostic parameter of the A-ASSOCIATE 
confirm primitive, unless it has the value of "null." In this 
case, a Diagnostic value is not included. 

7.1.5.9 Implementation Information 

For the accepting ACPM: The value assigned to this field is 
determined within the implementation of the ACPM. It con- 
tains information specific to the individual implementation of 
that ACPM. It is not used in negotiation. 

For the requesting ACPM: This field does not affect the 
operation of the ACPM. Any use depends on a common un- 
derstanding between the accepting and requesting ACPMs. 

7.1.5.10 User Information 

For the accepting ACPM: This value is determined by the 
value of the User Information parameter of the A-AS- 
SOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the User Information parameter of the A-AS- 
SOCIATE confirm primitive. 

7.1 .6 Collisions and interactions 

7.1.6.1 A-ASSOCIATE service 

For a given ACPM, an A-ASSOCIATE collision cannot occur 
(see 6.4.6). For a given AE, two distinct ACPMs would be 
involved that represent the processing for two distinct as- 
sociations: 

a) an ACPM that processes the initial A-ASSOCIATE re- 
quest primitive that results in the sending of an AARQ as 
user data on a P-CONNECT request primitive; and 

b) an ACPM that processes the subsequently received 
AARQ APDU as user data on a P-CONNECT indication 
primitive. 

7.1.6.2 A-ABORT, P-U-ABORT, or P-P-ABORT service 

If an ACPM receives an A-ABORT request primitive, a P-U- 
ABORT indication primitive, or a P-P-ABORT indication primi- 
tive, it discontinues the normal association establishment 
procedure, and instead follows the abnormal release proce- 
dure. 

7.2 Normal release of an association 

7.2.1 Purpose 

This procedure is used for the normal release of an associa- 
tion by an AE without loss of information in transit. It sup- 
ports the A-RELEASE service. 
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7.2.2 APDUtuMd 

The normal release procedure uses the A-RELEASE-RE- 
QUEST (RLRQ) APDU and the A-RELEASE-RESPONSE 
(RLRE) APOU. The fields of the RLRQ APDU are listed in 
table 4. The fields of the RLRE APDU are listed in table 5. 



Table 4 - RLRQ APDU fields 



Field neme 


Presence 


Source 


Sink 


"Reason 
User Information 


U 
U 


req 
req 


ind 
ind 



Table 5 • RLRE APDU fields 



Fieldname 


Presence 


Source 


Sink 


Reason 

User Information 


U 
U 


rsp 
rsp 


cnf 
cnf 



7.2.3 Normal release procedure 

This procedure is driven by the following events: 

a) an A-RELEASE request primitive from the requestor; 

b) an RLRQ APDU as user data on a P-RELEASE indica- 
tion primitive; 

c) an A-RELEASE response primitive from the acceptor; 
or 

d) an RLRE APDU as user data on a P-RELEASE confirm 
primitive. 

7.2.3.1 A-RELEASE request primitive 

7.2.3.1 .1 When an A-RELEASE request primitive is received, 
the ACPM sends an RLRQ APDU as user data on a P- 
RELEASE request primitive using the parameters from the A- 
RELEASE request primitive. 

NOTE - The requestor is required to meet the presentation land 
session) requirements in order to issue an A-RELEASE request 
primitive (eee 6.2 end 6.3). 



7.2.3.1.2 The requesting ACPM now waits for a primitive 
from the presentation service-provider. It does not accept 
any primitives from the requestor other than an A-ABORT re- 
quest primitive. 

7.2.3.2 RLRQ APDU 

When the accepting ACPM receives the RLRQ APDU as user 
data on a P-RELEASE indication primitive, it issues an A- 
RELEASE indication primitive to the acceptor. It does not ac- 
cept any ACSE primitives from its service-user other than an 
A-RELEASE response primitive or an A-ABORT request 
primitive. 

7.2.3.3 A-RELEASE response primitive 

The Result parameter on the A-RELEASE response primitive 
specifies whether the acceptor accepts or rejects the release 
of the association. The accepting ACPM forms an RLRE 
APDU from the response primitive parameters. The RLRE 
APDU is sent as user data on a P-RELEASE response primi- 
tive. 

a) If the acceptor accepted the release, the Result 
parameter of the P-RELEASE response primitive has a 
Result parameter value of "affirmative. " The association 
is released. 

b) If the acceptor rejected the release, the Result 
parameter of the P-RELEASE response primitive has a 
Result parameter value of "negative." The association 
continues. 

NOTE — To give a negative response, the acceptor is required to 
meet the related presentation (and session) requirements, (see 
6.3) 

7.2.3.4 RLRE APDU 

The requesting ACPM receives a P-RELEASE confirm primi- 
tive containing an RLRE APDU from its peer. The Result 
parameter on the P-RELEASE confirm primitive specifies 
either that the acceptor agrees or disagrees that the associa- 
tion may be released. The requesting ACPM forms an A- 
RELEASE confirm primitive from the RLRE APDU fields. 

a) If the Result parameter on the P-RELEASE confirm 
primitive specifies "affirmative", the association is 
released. 

b) If the Result parameter on the P-RELEASE confirm 
primitive specifies "negative", the association continues. 
The requesting ACPM again accepts primitives from its 
service-user. 
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7.2.3.5 A-RELEASE service collision 

7.2.3.5.1 An A-RELEASE service collision occurs when an 
ACPM has sent out an RLRQ APDU as the user data of a P- 
RELEASE request primitive (as a result of receiving an A- 
RELEASE request primitive from its service-user). Instead of 
receiving the expected RLRE APDU as user data on a P- 
RELEASE confirm primitive from its peer, it receives an RLRQ 
APDU as the user data of a P-RELEASE indication primitive. 

7.2.3.5.2 The ACPM issues an A-RELEASE indication primi- 
tive to its service-user. The procedure then followed by an 
ACPM depends on whether its service-user was the associa- 
tion-initiator or the association-responder. 

a) For the association-initiator: 

1) The ACPM waits for an A-RELEASE response 
primitive from its service-user. When it receives the 
response primitive , it forms an RLRE APDU from the 
response primitive's parameters. The RLRE is sent as 
user data on a P-RELEASE response primitive. The as- 
sociation continues. 

2) This ACPM now waits for an RLRE from its peer 
as user data on a P-RELEASE confirm primitive. It 
does not accept any primitive from its service-user 
other than an A-ABORT request primitive. 

3) When the ACPM receives the RLRE, it forms an A- 
RELEASE confirm primitive from the RLRE fields and 
issues it to its service-user. The association is 
released. 

In summary, the sequence of events that drive the ACPM 
of the association-initiator are: 

— A-RELEASE request primitive; 

— RLRQ APDU (causing the collision); 

— A-RELEASE response primitive; and finally, 

— RLRE APDU. 

b) For the association-responder: 

1 ) The ACPM waits for an RLRE from its peer as user 
data on a P-RELEASE confirm primitive. It does not 
accept a primitive from its service-user other than an 
A-ABORT request primitive. 

2) When this ACPM receives the RLRE, it forms an A- 
RELEASE confirm primitive from the RLRE fields. The 
association continues. 

3) The ACPM now waits for an A-RELEASE response 
primitive from its service-user. When it receives the 
response primitive , it forms a RLRE APDU from the 
response primitive's parameters. The RLRE is sent as 
user data on a P-RELEASE response primitive. The as- 
sociation is released. 

In summary, the sequence of events that drive the ACPM 
of the association-responder are: 



— A-RELEASE request primitive; 

— RLRQ APDU (causing the collision); 

— RLRE APDU; and finally 

— A-RELEASE response primitive. 

7.2.4 Use of the RLRQ APDU fields 

The RLRQ APDU fields are used by the requesting and ac- 
cepting ACPMs as specified below. 

7.2.4.1 Reason 

For the requesting ACPM: This value is determined by the 
value of the Reason parameter of the A-RELEASE request 
primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Reason parameter of the A-RELEASE indication 
primitive. 

7.2.4.2 User Information 

For the requesting ACPM: This value is determined by the 
value of the User Information parameter of the A-RELEASE 
request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the User Information parameter of the A-RELEASE 
indication primitive. 

7.2.5 Dse of the RLRE APDU fields 

The RLRE APDU fields are used by the accepting and request- 
ing ACPMs as specified below. 

7.2.5.1 Reason 

For the accepting ACPM: This value is determined by the 
value of the Reason parameter of the A-RELEASE response 
primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Reason parameter of the A-RELEASE con- 
firm primitive. 

7.2.5.2 User Information 

For the accepting ACPM: This value is determined by the 
value of the User Information parameter of the A-RELEASE 
response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the User Information parameter of the A- 
RELEASE confirm primitive. 

7.2.8 Collisions end interactions 

7.2.8.1 A-RELEASE service 

For a given ACPM, an A-RELEASE service collision can 
occur. The processing for such a collision is described in 
7.2.3.5. 
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NOTE - An A-RELEASE service collision can only occur if no ses- 
sion tokens were selected for the association. 

7.2.6.2 A-ABORT service, P-U-ABORT, or P-P-ABORT ser- 
vice 

If an ACPM receives an A-ABORT request primitive, a P-U- 
ABORT indication primitive, or a P-P-ABORT indication primi- 
tive, it disrupts the normal association release procedure, 
and instead follows the abnormal release procedure. 

7.3 Abnormal release of an association 

7.3.1 Purpose 

The Abnormal Release procedure can be used at any time to 
force the abrupt release of the association by a requestor in 
either AE, by either ACPM or by the presentation service- 
provider. When the abnormal release procedure is applied 
during an attempt to establish an association, the associa- 
tion is not established. The abnormal release procedure sup- 
ports the A-ABORT and A-P-ABORT services. 

7.3.2 APDUs used 

The abnormal release procedure uses the A-ABORT (ABRT) 
APDU. The fields of the ABRT APDU are listed in Table 6. 

NOTE - No APDUs are defined for the A-P-ABORT service since 
it is directly mapped from the P-P-ABORT service. 



Table 6 -ABRT APDU fields 



Field nam* 


Pr$$%t\c% 


Source 


Sink 


Abort Source 
User Information 


M 
U 


sp 
req 


ind 
ind 



7.3.3 Abnormal release procedure 

This procedure is driven by the following events: 

a) an A-ABORT request primitive from the requestor; 

b) a P-U-ABORT indication primitive; 

c) a P-P-ABORT indication primitive; or 

d) a protocol error detected by an ACPM. 



7.3.3.1 A-ABORT request primitive 

When an ACPM receives an A-ABORT request primitive from 
its service-user, the processing that it performs depends on 
the version of the underlying session-protocol (ISO 8327) 
that supports the association as specified below. 

a) For version 1 , the ACPM does not send any of its APCI 
to its peer. It simply issues a P-U-ABORT request primi- 
tive. If user information is included on the A-ABORT re- 
quest primitive, that user information is passed as user 
data on the P-U-ABORT request primitive. The associa- 
tion is released. 

b) For other versions, the ACPM sends an ABRT APDU 
as user data on a P-U-ABORT request primitive. The 
Abort Source field is specified as "ACSE service-user." If 
the User Information parameter is included on the A- 
ABORT request primitive, it is included in the ABRT 
APDU. The association is released. 

7.3.3.2 P-U-ABORT indication primitive 

When an ACPM receives a P-U-ABORT indication primitive, 
the User Data parameter may contain 1 an ABRT APDU. 

a) If the indication primitive does not contain an ABRT 
APDU, the ACPM issues an A-ABORT indication primitive 
with the Abort Source parameter specified as "ACSE ser- 
vice-user." If user data is contained on the P-U-ABORT 
indication primitive, it is included as the User Information 
parameter of the A-ABORT indication primitive. The as- 
sociation is released. 

b) If the indication primitive does contain an ABRT 
APDU, the ACPM issues an A-ABORT indication primitive 
using the Abort Source field of the ABRT APDU. If a User 
Information field is contained in the ABRT APDU, it is in- 
cluded on the A-ABORT indication primitive. The as- 
sociation is released. 

7.3.3.3 P-P-ABORT indication primitive 

When an ACPM receives a P-P-ABORT indication primitive, 
the ACPM issues an A-P-ABORT indication primitive to the 
acceptor. The association is released. 

7.3.3.4 Protocol errors 

7.3.3.4.1 Two types of ACSE protocol errors are possible: 

a) for a particular ACPM state, an unexpected APDU is 
received; or 

b) an invalid field is encountered during the processing 
of an incoming APDU (see 7.4). 



If an association is supported by version 1 of the session-protocol (130 8327), the User Data parameter does not contain an ABRT APDU 
(see 7.3.3.1). The absence of an APDU in this situation does not imply that the application is operating In the X.410-1984 mode. 



!* 
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7.3.3.4.2 If an unexpected APDU is received, the abnormal 
release procedure is invoked. If an invalid field is detected 
by an ACSE procedure, that procedure is disrupted and the 
abnormal release procedure is invoked. 

7.3.3.4.3 As part of the abnormal release procedure, the 
ACPM issues an A-ABORT indication primitive to its service- 
user, unless the error occurred during the association estab- 
lishment procedure 1 as the result of receiving an invalid 
AARQ (see 7.4). If an indication primitive is issued, the value 
of the Abort Source is "ACSE service-provider." The User 
Information parameter is not used as specified below. 

7.3.3.4.4 The subsequent ACPM processing performed 
depends on the version of the underlying session-protocol 
(ISO 8327) that supports the association as specified below. 

a) For version 1 , the ACPM issues a P-U- ABORT request 
primitive. No user information is included. 

b) For other versions, the ACPM sends an ABRT APDU 
as user data on a P-U-ABORT request primitive. The 
Abort Source field is specified as "ACSE service- 
provider." The User Information field is not used. 

7.3.3.4.5 In either case, the association is released. 

7.3.4 Use of the ABRT APDU fields 

The ABRT APDU fields are used by the requesting and ac- 
cepting ACPMs as specified below. 

7.3.4.1 Abort Source 

For the requesting ACPM: This value is assigned by the 
ACPM as specified below. 

a) If the ACPM initiated the abort procedure, the ACPM 
assigns the value of "ACSE service-provider." 

b) Otherwise, the ACPM assigns the value of "ACSE ser- 
vice-user." 

For the accepting ACPM: This value is used to determine the 
value of the Abort Source parameter of the A-ABORT indica- 
tion primitive. 

7.3.4.2 User Information 

For the requesting ACPM: This value is determined by the 
value of the User Information parameter of the A-ABORT re- 
quest primitive. 



For the accepting ACPM: This value is used to determine the 
value of the User Information parameter of the A-ABORT in- 
dication primitive. 

7.3.5 Collisions and interactions 

The abnormal release procedure may be used whenever an 
association is established, is in the process of being estab- 
lished, or is being normally released. This procedure disrupts 
any other currently active procedure. A P-P-ABORT indica- 
tion primitive can disrupt the A-ABORT procedure with loss 
of the A-ABORT information. Collisions of ABRT APDUs are 
governed by the P-U-ABORT services (ISO 8822). 

7.4 Rules for extensibility 

7.4.1 When processing an incoming AARQ, the accepting 
ACPM shall: 

a) ignore all tagged values that are not defined in the 
abstract syntax of this International Standard; and 

b) ignore all unknown bit name assignments within a bit 
string. 

7.4.2 After the association has been established or during 
the establishment of an association, only those ACSE 
APDUs and related APDU fields defined in the ASN.1 
description of the negotiated version of this International 
Standard shall be issued. 

7.4.3 A received APDU or field within an APDU which is not 
defined in the ASN.1 description of the negotiated version 
of this International Standard shall be treated as a protocol 
error. 



8 Mapping to the presentation-service 

This clause specifies how the presentation service primitives 
are used by the ACPM. This usage depends on the mode 
selected (see 6.2) for the association. 

a) For the requesting ACPM: The mode for the associa- 
tion is determined by the value of the Mode parameter of 
the invoking A-ASSOCIATE request primitive. If the 
Mode parameter is not included on the request primitive, 
the default value of "normal" is used. 

b) For the accepting ACPM: The mode is determined by 
the value of the Mode parameter of the incoming P-CON- 
NECT indication primitive. 



Since an A-ASSOCIATE indication primitive will not be issued, an A-ABORT indication primitive would have no meaning, and, therefore. 
it is not issued. 
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Table 7 - Mapping Overview 




ACSE primitive 


APDU* 


Presentation Primitive 


A- ASSOCIATE request/Indication 
A-ASSOCIATE response/confirm 


AARG 
AARE 


P-CONNECT request/indication 
P-CONNECT response/confirm 


A-RELEASE request/indication 
A-RELEASE response/confirm 


RLRQ 
RLRE 


P-RELEASE request/indication 
P-RELEASE response/confirm 


A- ABORT request/indication 
A-P- ABORT indication 


ABRT 


P-U-ABORT request/indication 
P-P-ABORT indication 



- ACSE APDUs are not used in the X.410-1984 mode. 



Subclauses 8. 1 to 8.3 specify the usage of the presentation 
services for the normal mode. Subclauses 8.4 to 8.6 specify 
the usage for the X. 41 0-1 984 mode. Table 7 summarizes, 
for both modes, the mapping of ACSE primitives and their re- 
lated APDUs (normal mode) to the presentation primitives 
used. 

8.1 Association establishment (normal mode) 

The association establishment procedure uses the P-CON- 
NECT service. Association establishment takes place con- 
currently with the establishment of the underlying presenta- 
tion-connection. 

8.1 .1 Directly mapped parameters 

For the P-CONNECT primitives: The following parameters 
are not referenced by the ACPM and are mapped directly 
onto the corresponding parameters of the A-ASSOCIATE 
primitives: 

a) Calling Presentation Address; 

b) Called Presentation Address; 

c) Responding Presentation Address; 

d) Presentation Context Definition List; 

e) Presentation Context Definition Result List; 

f) Default (Presentation] Context Name; 

g) Default (Presentation] Context Result; 
h) Quality of Service; 

i) Presentation Requirements; 

j) Session Requirements; 

k) Initial Synchronization Point Serial Number; 



I) Initial Assignment of Tokens; and 

m) Session-connection Identifier. 

8.1 .2 Use of other P-CONNECT request and indication 
parameters 

The Mode and User Data parameters of the P-CONNECT re 
quest and indication primitives are referenced by the ACPM 

8.1.2.1 Mode 

8.1.2.1.1 For the P-CONNECT request primitive: The Mod 
parameter is set to the value of the Mode parameter of trv 
A-ASSOCIATE request primitive. For the normal mode o 
ACSE operation, this parameter has the value of "normal.' 
This indicates to the presentation-service that it is to operat 
in the normal mode for this presentation-connection. 

8.1.2.1.2 For the P-CONNECT indication primitive: Thi, 
parameter has the value of "normal" for the normal mode o 
ACSE operation. The value indicates that the accepting 
ACPM is to operate in the normal mode for this association 
The Mode parameter of the A-ASSOCIATE indication primi 
tive is set to the value of "normal." 

8.1.2.2 User Data 

For both the P-CONNECT request and indication primitives 
The User Data parameter is used to carry the AARQ APDL 
as specified below. 

a) The APCI of the AARQ APDU is expressed using the 
ACSE abstract syntax of this International Standard. ThL 
abstract syntax must be included as the value of a preser 
tation context definition parameter specified by the re 
questor on the A-ASSOCIATE request primitive. 

NOTE — The requesting and accepting ACPMs are aware of th 
presentation context that contains their abstract syntax by a loc 
mechanism. 

b) User information (if any) from the A-ASSOCIATE re 
quest primitive is included in the AARQ APDU and is ex 
pressed using one or more presentation context 
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specified by the requestor on the A-ASSOCIATE request 
primitive. 

8.1 .3 Use of other P-CONNECT response and confirm 
parameters 

The User Data and Result parameters of the P-CONNECT 
response and confirm primitive are referenced by the ACPM. 

8.1.3.1 Result 1 

8.1.3.1.1 For the P-CONNECT response primitive: The 
Result parameter is set by the accepting ACPM as specified 
below. 

a) If the accepting ACPM itself rejects the association, 
it is set as "user-rejection." 

b) If the accepting ACPM accepts the request, the value 
is set as "acceptance", or "user-rejection" as determined 
by the value of the corresponding Result parameter on the 
A-ASSOCIATE response primitive. 

8. 1 .3.1 .2 For the P-CONNECT confirm primitive: The Result 
parameter is used by the requesting ACPM to determine if 
the P-CONNECT confirm primitive User Data parameter con- 
tains an AARE APDU as specified below. 

a) If the Result parameter has the value "provider-rejec- 
tion", the request is rejected by the presentation service- 
provider. The intended accepting ACPM never received 
the AARQ APDU. The User Data parameter does not con- 
tain an AARE APDU. 

b) Otherwise, the Result parameter has the value of "ac- 
ceptance" or "user rejection." The accepting ACPM 
received the AARQ APDU and has returned an AARE 
APDU that is contained in the User Data parameter. 

8.1.3.2 User Data 

8.1.3.2.1 The User Data field only has relevance if the P- 
CONNECT request primitive was not rejected by the presen- 
tation service-provider (see 8.1 .3.1). 

8.1.3.2.2 For both the P-CONNECT response and confirm 
primitives: The User Data parameter is used to carry the 
AARE APDU as specified below. 

a) The APCI of the AARE APDU is expressed using the 
ACSE abstract syntax of this International Standard. This 
abstract syntax must be included as the value of a presen- 
tation context definition parameter selected by the ac- 
ceptor on the A-ASSOCIATE response primitive. 

b) User information (if any) from the A-ASSOCIATE 
response primitive is included in the AARE APDU and is 



expressed using one or more presentation contexts 
selected by the acceptor on the A-ASSOCIATE response 
primitive. 

8.2 Normal release of an association (normal mode) 

The normal release procedure uses the P-RELEASE service. 
The normal release of an association takes place simul- 
taneously with the normal release of the underlying presen- 
tation-connection. 

8.2.1 Use of P-RELEASE request and indication 
parameters 

The User Data parameter of the P-RELEASE request and in- 
dication primitives is referenced by the ACPM. 

For both the P-RELEASE request and indication primitives: 
The User Data parameter is used to carry the RLRQ APDU as 
specified below. 

a) The APCI of the RLRQ APDU is expressed using the 
ACSE abstract syntax of this International Standard. This 
abstract syntax must be one of the available presentation 
contexts. 

b) User information (if any) from the A-RELEASE request 
primitive is included in the RLRQ APDU and is expressed 
using one or more available presentation contexts. 

8.2.2 Use of P-RELEASE response and confirm parameters 

The Result and User Data parameters of the P-RELEASE 
response and confirm primitives are referenced by the 
ACPM. 

8.2.2.1 Result 

8.2.2. 1 . 1 For the P-RELEASE response primitive: The Result 
parameter is set to the value of the Result parameter of the 
A-RELEASE response primitive (i.e., "affirmative" or "nega- 
tive"). This value indicates to the presentation service- 
provider whether the underlying presentation-connection is 
to be released or if it is to be continued. 

8.2.2.1.2 For the P-RELEASE confirm primitive: The value 
of the Result parameter on the A-ASSOCIATE confirm primi- 
tive is set to the value of the Result parameter. This value 
indicates to the requesting ACPM whether the association 
is released or if it continues. 

8.2.2.2 User Data 

For both the P-RELEASE response and confirm primitives: 
The User Data parameter is used to carry the RLRE APDU as 
specified below. 



The AARE APDU also has a Result field that must correspond to the value of this presentation parameter. The Result parameter of the 
A-ASSOCIATE confirm primitive is determined by the Result field of the AARE APDU. 
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a) The APCI of the RLRE APDU is expressed using the 
ACSE abstract syntax of this International Standard. This 
abstract syntax must be one of the available presentation 
contexts. 

b) User information (if any) from the A-RELEASE 
response primitive is included in the RLRE APDU and is 
expressed using one or more available presentation con- 
texts. 

8.3 Abnormal release of an association (normal 
mode) 

The abnormal release procedure uses the P-U- ABORT and P- 
P-ABORT services. The abnormal release of an association 
takes place simultaneously with the abnormal release of the 
underlying presentation-connection. 

8.3.1 Use of P-U-ABORT request and indication 
parameters 

The User Data parameter of the P-U-ABORT request and in- 
dication primitives is referenced 1 by the ACPM. 

For both the P-U-ABORT request and indication primitives: 
The User Data parameter is used to carry the ABRT APDU 
as specified below. 

a) The APCI of the ABRT APDU is expressed using the 
ACSE abstract syntax of this International Standard. This 
abstract syntax must be one of the available presentation 
contexts. 

b) User information (if any) from the A-ABORT request 
primitive is expressed using one or more available presen- 
tation contexts. 

8.3.2 Use of P-P-ABORT indication parameter 

The Reason parameter of the provider-initiated P-P-ABORT 
indication primitive is mapped directly to the corresponding 
parameter of the A-P-ABORT indication. 

8.4 Association establishment (X.410-1984 mode) 

The association establishment procedure uses the P-CON- 
NECT service. 



8.4.1 Directly mapped parameters 

The following parameters are not referenced by the ACPM 
and are mapped directly onto corresponding parameters of 
the A-ASSOCIATE primitives: 

a) User data; 2 

b) Calling Presentation Address; 

c) Called Presentation Address; 

d) Responding Presentation Address; 

e) Quality of Service; 

f) Session Requirements; 

g) Initial Synchronization Point Serial Number; 
h) Initial Assignment of Tokens; and 

i) Session-connection identifier. 

8.4.2 Use of other P-CONNECT request and indication 
parameters 

The Mode parameter of the P-CONNECT request and indica- 
tion primitives is referenced by the ACPM. 

For the P-CONNECT request primitive: The Mode parameter 
is set to the value of the Mode parameter of the A-AS- 
SOCIATE request primitive. For the X. 41 0-1 984 mode of 
ACSE operation, this parameter has the value of "X.410- 
1 984." This indicates to the presentation-service that it is 
to operate in the X. 410-1 984 mode for this presentation- 
connection. 

For the P-CONNECT indication primitive: This parameter has 
the value of "X.410-1984" for the X.410-1984 mode of 
ACSE operation. This value indicates that the accepting 
ACPM is to operate in the X.410-1984 mode for this as- 
sociation. The Mode parameter of the A-ASSOCIATE indica- 
tion primitive is set to the value of "X.410-1984." 

8.4.3 Use of other P-CONNECT response and confirm 
parameters 

The Result parameter of the P-CONNECT response and con- 
firm primitives is used by the ACPM when operating in the 
X.410-1984 mode. 



1 If bo association is supported by version 1 of the session-protocol (ISO 8327), the User Data parameter is not referenced by the ACPM 
(because of length constraints) and is mapped directly onto the User Information parameter of the A-ABORT primitives (see 7.3.3. 1 ) 

2 User Data is mapped directly onto the A-ASSOCIATE User Information parameter. No explicit presentation context is available for it. 
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For the P-CONNECT response primitive: The value of the 
Result parameter is mapped from the Result parameter of the 
A-ASSOCIATE Result parameter as shown in table 8. 

For the P-CONNECT confirm primitive: The Result and Result 
Source parameters of the A-ASSOCIATE confirm primitive 
are mapped from the Result parameter as shown in table 9. 



Table 8 - Mapping ACSE Result 



A-ASSOCIATE's 
Result 


P-CONNECT'i 
Result 


accepted 


acceptance 


rejected(permanent) 


user-rejection 


rejected(transient) 


user-rejection 



8.6 Abnormal release of an association 
(X.41 0-1 984 mode) 

The abnormal release procedure uses the P-U-ABORT and P- 
P-ABORT services. 

8.6.1 U§* of P-U-ABORT request and indication 
parameters 

For both the P-U-ABORT request and indication primitives: 
The User Data parameter is not referenced by the ACPM and 
is mapped directly onto the User Information parameter of 
the corresponding A-ABORT primitives. 

8.6.2 Use of P-P-ABORT indication parameter 

For the P-P-ABORT indication primitive: The Reason 
parameter is not referenced by the ACPM and is mapped 
directly onto the corresponding parameter of the A-P-ABORT 
indication primitive. 



Table 9 - Mapping Presentation Result Parameter 



P-CONNECT's 
Rtsult 


A-ASSOCIATE's 
Result 


A-ASSOCIATE's 
Result Source 


acceptance 


accepted 

rejected 
(permanent) 

rejected 
(permanent) 


ACSE 
service-user 


User-rejection 


ACSE 
service-user 


provider-rejection 


presentation 
service-provider 



8.5 Normal release of an association (X.41 0-1 984 
mode) 

The normal release procedure uses the P-RELEASE service. 
The following parameters are not referenced by the ACPM 
and are mapped directly onto corresponding parameters of 
the A-RELEASE primitives: 

a) Result; and 

b) User Data. 
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9 Structure and encoding of ACSE APDUs 

9.1 The abstract syntax of each of the ACSE APDUs is specified in this clause using ASN.1 (ISO 8824). 



ACSE-1 DEFINITIONS ::* 

BEGIN 

— ACSE-1 refers to ACSE version 1 



ACSE-apdu 



CHOICE 



{ aarq AARQ-apdu, 

aare AARE-apdu, 

rlrq RLRQ-apdu, 

rlre RLRE-apdu, 

abrt ABRT-apdu 

} 



AARQ-apdu ::- [ APPLICATION ] IMPLICIT SEQUENCE 
{ protocol -vers ion 



appl i cati on-context-name 

called-AP-title 

called-AE-qualifier 

called-AP-invocation-identifier 

called-AE-invocation-identifier 

calling-AP-title 

call ing-AE-quali tier 

calling-AP-invocation-identifier 

calling-AE-invocation-identifier 

iwpl ementati on-i nf ormat i on 

user- information 



} 



[0] IMPLICIT BIT STRING 

( versionl (0) } 

DEFAULT ( versionl }, 
[1] Appl i cation-context-name, 

[2] AP-title 

OPTIONAL, 
[3] AE-qualifier 

OPTIONAL, 
[4] AP-invocat ion-identifier 

OPTIONAL, 
[5] AE- i nvocat i on-i dent i f i er 

OPTIONAL, 
[6] AP-title 

OPTIONAL, 
[7] AE-qualifier 

OPTIONAL, 
[8] AP-invocation-identifier 

OPTIONAL. 
[9] AE-invocation-identifier 

OPTIONAL, 
[29] IMPLICIT Implementation-data 

OPTIONAL, 
[30] IMPLICIT Association-information 

OPTIONAL 
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AARE-apdu ::- [APPLICATION 1 ] IMPLICIT SEQUENCE 

{ protocol -version [0] IMPLICIT BIT STRING 

( versionl (0) } 
DEFAULT { versionl }. 
appli cation-context-name [1] Appli cation-context-name, 

result [2] Associate-result, 

resul t-source-di agnosti c [3] Associ ate-source-di agnosti c , 

respondi ng-AP-ti tie [4] AP-title 

OPTIONAL. 
responding-AE-qualifier [5] AE-qualifier 

OPTIONAL, 
respondi ng-AP-invocation-identifier [6] AP-invocation-identifier 

OPTIONAL, 
respondi ng-AE-invocat ion-identifier [7] AE-invocation-identifier 

OPTIONAL. 
Implementation-information [29] IMPLICIT Implementation-data 

OPTIONAL, 
user-information [30] IMPLICIT Association-information 

OPTIONAL 
) 

RLRQ-apdu ::* [ APPLICATION 2 ] IMPLICIT SEQUENCE 

( reason [0] IMPLICIT Release-request-reason 

OPTIONAL, 
user-information [30] IMPLICIT Association-information 

OPTIONAL 
} 

RLRE-apdu ::« [ APPLICATION 3 ] IMPLICIT SEQUENCE 

{ reason [0] IMPLICIT Release-response-reason 

OPTIONAL, 
user-information [30] IMPLICIT Association-information 

OPTIONAL 

} 

ABRT-apdu ::- [ APPLICATION 4 ] IMPLICIT SEQUENCE 

{ abort-source [0] IMPLICIT ABRT-source. 

user-information [30] IMPLICIT Association-information 

OPTIONAL 

} 
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ABRT-source ::» INTEGER 

{ acse-service-user (0), 

acse-service-provider (1) 

} 



Appli cation-context-name ::« OBJECT IDENTIFIER 



AP-title ::• ANY 

— The exact definition and values used for AP-title 

— should be chosen taking into account the ongoing 

— work in areas of naming, the Directory, and the 

— Registration Authority procedures for AP titles, 

— AE-ti ties and AE qualifiers. 



AE-qualifier ::« ANY 

-- The exact definition and values used for AE-qualifier 
-- should be chosen taking into account the ongoing 
-- work in areas of naming, the Directory, and the 
-- Registration Authority procedures for AP titles, 
-- AE-titles and AE qualifiers. 



— As defined in ISO 7498-3, an application-entity title is composed of 

— an application-process title and an appli cat ion -entity qualifier. 

— The ACSE protocol provides for the transfer of an appli cat ion -entity 

— title value by the transfer of its component values. However, the 

— following data type is provided for reference by other International 

— Standards that require a single syntactic structure for AE titles. 

AE-title ::« SEQUENCE {AP-title, 

AE-qualifier 
} 

AE-invocation-identlfier ::- INTEGER 
AP-1nvocation-ident1f1er ::« INTEGER 

Associate-result ::- INTEGER 

{ accepted (0) 

rejected-permanent (1) 

rejected-transient (2 > 
> 
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Associate -source -diagnostic ::■ CHOICE 

( ecse-service-user [1] INTEGER 
{ null (0). 
no-reason-given (1). 

appl i cat ion -context -name -not -supported (2) 9 
calling-AP-ti tie-not-recognized (3), 
calling-AP-invocation-identifier-not-recognized (4), 
cal 1 i ng-AE-qual i f 1 er-not-recogni zed (5) , 
cal 1 1 ng-AE-i nvocati on-i dent i f 1 er-not-recogni zed (6) , 
call ed-AP-ti tie-not-recognized (7) , 
cal 1 ed-AP- i nvocat i on -identifi er-not-recogni zed (8), 
cal 1 ed-AE-qual i f i er-not-recogni zed (9) , 
cal led-AE- invocation- identifier-not-recognized (10) 

}, 

acse-service-provider [2] INTEGER 
{ null (0). 

no-reason-given (1), 

no-common-acse-version (2) 

} 
} 



Association-information ::« SEQUENCE OF EXTERNAL 
Implementation-data ::* GraphicString 

Release-request-reason ::• INTEGER 

( normal (0) 9 

urgent (1), 

user-defined (30) 
} 

Release-response-reason : :■ INTEGER 

{ normal (0) 9 

not-finished (1), 

user-defined (30) 

} 



END 

9.2 The following name, that has the ASN.l type of OBJECT IDENTIFIER, applies to the ACSE abstract-syntax-definition, 
specified in this cl 



g nam 
:lause. 



( joint-iso-ccitt association-control (2) abstract-syntax (1) 

apdus(O) versionl(l) 
} 

9.3 The set of encoding rules named 

( jotnt-fso-ccftt asnl(l) basictncoding(l) } 

and specified in ISO 882$ is applicable to the ACSE abstract syntax definition. 
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10 Conformance 

A system claiming to implement the procedures specified in 
this International Standard shall comply with the require- 
ments In 10.1 through 10.3. 

Two modes of conformance are recognized: 

a) normal mode; and 

b) X.410-1 984 mode. 

The X.410-1 984 mode exists to allow claims of confor- 
mance to be made for message handling systems im- 
plementing the CCITT X.410-1 984 series of Recommenda- 
tions, and, therefore, use the X.410-1 984 mode of ACSE. 

10.1 Statement requirements 

The following shall be stated by the implementor: 

a) whether the system \s capable of acting in the role of 
association-initiator, or association-responder, or both; 

b) that the system supports version 1 of this protocol; 
and 

c) whether the system implements: 

1 ) the normal mode of ACSE protocol; 

2) the X.410-1 984 mode of ACSE protocol because 
it supports a message handling system implementing 
the CCITT X. 400-1 984 series of Recommendations; 
or 

3) both the normal mode and the X.410-1 984 mode 
for the reason given in item 2) above. 

10.2 Static requirements 

The use of the Association Control Service Element is re- 
quired for an application-entity to meet the rhinimum require- 
ments for establishing and releasing communication with a 
peer entity. 

10.2.1 Normal mode 

If the normal mode is implemented, the system shall: 

a) act in the role of an association-initiator (by sending 
an AARQ APDU), or in the role of an association-acceptor 
(by responding properly to an AARQ APDU with an ap- 
propriate A ARE APDU), or act in both roles; and 

b) support ias a minimum) that encoding which results 
from applying the basic ASN.1 encoding rules to the 
ASN.1 specified in clause 9 for the purpose of exchang- 
ing ACSE APCI. 



10.2.2 X.410-1 984 mode 

If the X.410-1 984 mode is implemented, the system shall 
act in the role of an initiator, or acceptor, or both. 

10.3 Dynamic requirements 

10.3.1 Normal mode 

If the normal mode is implemented, the system shall: 

a) follow all the procedures specified in clause 7 (includ- 
ing- the rules for extensibility) and Annex A; and 

b) support the mapping onto the Presentation Service 
defined in 8.1 to 8.3. 

10.3.2 X.410-1 984 mode 

If the X.410-1 984 mode is implemented, the system shall 
support the direct mapping of parameters of presentation- 
service primitives onto the ACSE primitives as specified in 
8.4 to 8.6. 

11 Precedence 

11.1 The aspects of the protocol for ACSE are specified in 
several clauses in this International Standard. This clause 
states the rules of precedence for possible situations where 
the same aspect may be specified in more than one place in 
an apparently inconsistent manner. The relevant aspects of 
protocol specification covered are: 

a) sequencing rules; 

b) mapping to the presentation-service; and 

c) structure and encoding of ACSE APDUs. 

1 1 .2 Annex A and clause 7 of this International Standard 
specify the elements of procedure which govern the behavior 
of the ACPM. Annex A takes precedence over any other 
clause in this International Standard which may state or 
imply apparently inconsistent sequencing rules. 

1 1 .3 Clause 8 specifies how the presentation service primi- 
tives are used by the ACPM. Clause 8 takes precedence 
over any other part of this International Standard which may 
state or imply mapping to the presentation-service. 

1 1 .4 Clause 9 specifies the structure and encoding of ACSE 
APDUs. Clause 9 takes precedence over any other part of 
this International Standard which may state or imply struc- 
ture and encoding of ACSE APDUs. 

NOTE - Any person encountering an Inaccuracy or ambiguity in 
this International Standard is requested to notify their National 
Body of ISO without delay In order that the matter may be Inves- 
tigated and appropriate action taken. 
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Annex A 
ACPM state table 

(This annex forms part of the standard.) 



A.1 General 

A.1.1 This annex defines a single Association Control 
Protocol Machine (ACPM) in terms of a state table. The 
state table shows the interrelationship between the state of 
an ACPM, the incoming events that occur in the protocol, 
the actions taken, and, finally, the resultant state of the 
ACPM. 

A. 1.2 The ACPM $tate table does not constitute d formal 
definition of the ACPM. It is included to provide a more 
precise specification of the elements of procedure defined in 
clause 7. 

A.1 .3 This annex contains the following tables. 

a) Table 1 specifies the abbreviated name, source, and 
name/description of each incoming event. The sources 
are: 

1) ACSE service-user (AC-user); 

2) peer ACPM (AC-peer); and 

3) presentation service-provider (PS-provider). 

b) Table 1 1 specifies the abbreviated name of each 
state. 

c) Table 1 2 specifies the abbreviated name, target, and 
name/description of each outgoing event. The targets 
are: 

1) ACSE service-user (AC-user); and 

2) peer ACPM (AC-peer). 

d) Table 1 3 specifies the predicates. 

e) Table 1 4 specifies the ACPM state table using the ab- 
breviations of the above tables. 

A.2 Conventions 

A.2.1 The intersection of an incoming event (row) and a 
state (column) forms a cell. 

A.2.2 In theitate table, a blank cell represents the combina- 
tion of an incoming event and a state that is not defined for 
the ACPM (see A.3.1). 

A.2.3 A non-blank cell represents an incoming event and 
state that is defined for the ACPM. Such a cell contains one 



or more action lists. An action list may be either mandatory 
or conditional. If a cell contains a mandatory action list, it is 
the only action list in the cell. 

A.2.4 A mandatory action list contains: 

a) an outgoing event; and 

b) a resultant state. 

A.2. 5 A conditional action list contains: 

a) a predicate expression comprising predicates and 
Boolean operators ( A represents the Boolean NOT); and 

b) a mandatory action list. (This mandatory action list is 
used only if the predicate expression is true.) 

A.3 Actions to be taken by the ACPM 

The ACPM state table defines the action to be taken by the 
ACPM in terms of an outgoing event and the resultant state 
of the ACPM. 

A.3.1 Invalid intersections 

Blank cells indicate an invalid intersection of an incoming 
event and state. If such an intersection occurs, one of the 
following actions is taken. 

a) If the incoming event comes from the ACSE service- 
user, any action taken by the ACPM is a local matter. 

b) If the incoming event is related to a received APDU or 
PS-provider event, the ACPM issues both an A-ABRind 
outgoing event (to its AC-user) and an ABRT outgoing 
event (to its peer ACPM). 

A.3.2 Valid intersections 

If the intersection of the state and incoming event is valid, 
one of the following actions is taken. 

a) If a cell contains a mandatory action list, the ACPM 
takes the actions specified; 

b) If a cell contains one or more conditional action lists, 
for each predicate expression that is true, the ACPM 
takes the actions specified. If none of the predicate ex- 
pressions are true, the ACPM takes one of the actions 
defined in A.3.1. 
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^>R-«ton.Np«oP,... n tttl.n.ndoth« ^-jjm-jj-mJjjjj^ 

MO " the ACPM state table because they do not affect the ACPM. 

The ACPM state table (table 1 4) only defines the interactions 
of the ACPM, its ACSE service-user and the presentation- 
services used by the ACPM. 
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Abbreviated 
Nam* 


Source 
AC-user 


Name and Description 


A-ASCreq 


A-ASSOCIATE request primitive 


A-ASCrsp + 


AC-user 


A-ASSOCIATE response primitive 
(Result - "accepted") 


A-ASCrsp- 


AC-user 


A-ASSOCIATE response primitive 
(Result » "rejected(permanent)" 
or "rejected(transient)") 


AARQ 


AC-peer 


A-ASSOOATE-REQUEST APDU 
The AARQ is user data on a 
P-CONNECT indication 


AARE + 


AC-peer 


A-ASSOCIATE-RESPONSE APDU 
(Result « "accepted") 
The AARE ♦ is user data on a 
P-CONNECT confirm primitive 
(Result - "acceptance") 


AARE- 


AC-peer 


A-ASSOCIATE-RESPONSE APDU 
(Result » "rejected(permanent)" 
or "rejected(transient)") 
The AARE- is user data on 
a P-CONNECT confirm primitive 
(Result » "user-rejection") 


P-CONcnf- 


PS-provider 


P-CONNECT confirm primitive 
(Result - "provider-rejection") 


A-RLSreq 


AC-user 


A-RELEASE request primitive 


A-RLSrsp + 


AC-user 


A-RELEASE response primitive 
(Result ■ "affirmative") 


A-RLSrsp- 


AC-user 


A-RELEASE response primitive 
(Result - "negative") 


RLRQ 


AC-peer 


A-RELEASE-REQUEST APDU 
The RLRO is user data on 
a P-RELEASE indication primitive 


RLRE + 


AC-peer 


A-RELEASE-RESPONSE APDU 
The RLRE + is user data on 
a P-RELEASE confirm primitive 
(Result - "affirmative") 


RLRE- 


AC-peer 


A-RELEASE-RESPONSE APDU 
The RLRE- is user data on 
a P-RELEASE confirm primitive 
(Result - "negative") 


A-ABRreq 


AC-user 


A-ABORT request primitive 


• ABRT 


AC-peer 


A-ABORT APDU 
The ABRT is user data on a 
P-U-ABORT indication primitive 


P-PABind 


PS-provider 
ed by version 1 of the 


P-P-ABORT indication primitive 


• - When support 


i session-protocol (ISO 8327), the A-ABORT 


APDU has no AP( 


SI. The receipt of the 


P-U-ABORT indication implies its existence. 



Table 1 1 - ACPM states 



Abbreviated 


Description 


Name 




STAO 


idle: unassociated 


STA1 


awaiting AARE APDU 


STA2 


awaiting A-ASSOCIATE response 


STA3 


awaiting RLRE APDU 


STA4 


awaiting A-RELEASE response 


STA5 


associated 


STA6 


awaiting A-RELEASE response 




(association -initiator) 


STA7 


awaiting RLRE APDU 




(association-responder) 
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Table 1 2 - Outgoing event Ret 


Abbreviated 


Target 


Name and Description 


Nan* 






A-ASCind 


AC-user 


A-ASSOCIATE indication primitive 


A-ASCcnf + 


AC-user 


A-ASSOCIATE confirm primitive 
(Result - "accepted") 


A-ASCcnf- 


AC-user 


A-ASSOCIATE confirm primitive 
(Result - "rejected(permenent)" 
or "reiected(transient)") 


AARQ 


AC-peer 


A-ASSOCIATE-REQUEST APOU 
The AARQ is sent as user data 
on a P-CONNECT request primitive 


AARE + 


AC-peer 


A-ASSOCIATE-RESPONSE APOU 
(Result - "accepted") 
The AARE + is sent as user data 
on a P-CONNECT + response primitive 
(Result - "acceptance") 


AARE- 


AC-peer 


A-ASSOCIATE-RESPONSE APOU 
(Result ■ "rejected(permanent)" 
or "rejected (transient)") 
The AARE- is sent as user data on 


• 




a P-CONNECT-response primitive 
(Result « "user-rejection") 


A-RLSind 


AC-user 


A-RELEASE indication primitive 


A-RLScnf + 


AC-user 


A-RELEASE confirm primitive 
(Result - "affirmative") 


A-RLScnf- 


AC-user 


A-RELEASE confirm primitive 
(Result - "negative") 


RIRQ 


AC-peer 


A-RELEASE-REQUEST APOU 
The RLRO is sent as user data on 
a P-RELEASE request primitive 


RLRE + 


AC-peer 


A-RELEASE-RESPONSE APOU 
The RLRE + is sent as user data 
on a P-RELEASE response primitive 
(Result - "affirmative") 


RLRE- 


AC-peer 


A-RELEASE-RESPONSE APOU 
The RLRE- is sent as user data on 
a P-RELEASE response primitive 
(Result - "negative") 


A-ABRind 


AC-user 


A-ABORT indication primitive 
(Source - "ACSE service-user" 
or "ACSE service-provider") 


• ABRT 


AC-peer 


A-ABORT APDU 
(Source - "ACSE service-user" 
or "ACSE service-provider") 
The ABRT is sent as user data on 
a P-U-ABORT request primitive 


A-PABIod 


AC-user 


A-P-ABORT indication primitive 


• - Whan support 


ad by version 1 of t 


to session-protocol (ISO 8327), the A-ABORT APOU 


haanoAPCI. Thi 


i receipt of the subs 


equent P-U-ABORT indication implies its existence. 



Tabic 13 -PradteatM 



»1 
I* 



Meaning 



ACPM can support requested connection 
ACPM originated this association 
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Table 14 • ACPM state table 





STAO 

MS- 

Uiaaaoc 


STA1 

AwaHing 

AARE 


d! 


STA3 

AwaHing 

RLRE 


sia ! 


STA5 
Assoc- 
iated 

s 


STA6 
Collision 
association 
initiator 


STA7 
Collision 
association 
responder 


A-ASCreq 


Pi 

AARQ 

8TA1 


A-ASCrap + 


AARE + 
ST^5 

~ AARE- 
STAO 


— ... 




i 


A-ASCrep- 






AARQ 


P1 

A-ASCind 

STA2 

*p1: 

AARE- 

STAO 
















aareV 




A-ASCcnf + 
STA5 














AARE- 




A-ASCcnf- 
STAO 














P-CONcnf- 




A-ASCcnf- 
STAO 














A-RLSreq 












RLRQ 
STA3 






A-RLSrsp + 










RLRE + 
STAO 




RLRE + 
ST A 3 




A-RLSrsp- 










RLRE- 
STA5 








RLRQ 








P2 

A-RLSind 

STA6 

A p2 

A-RLSind 

STA7 




A-RLSind 
STA4 






RLRE + 








A-RLScnf + 
STAO 








A-RLScnf + 
STA4 


RLRE- 








A-RLScnf- 
STA5 






< 




A-ABRreq 




ABRT 
STAO 


ABRT 
STAO 


ABRT 
STAO 


ABRT 
STAO 


ABRT 
STAO 


ABRT 
STAO 


ABRT 
STAO 


ABRT 




A-ABRind 
STAO 


A-ABRind 
STAO 


A-ABRind 
STAO 


A-ABRind 
STAO 


A-ABRind 
STAO 


A-ABRind 
STAO 


A-ABRind 
STAO 


P-PABind 




A-PABind 
STAO 


A-PABind 
STAO 


A-PABind 
STAO 


£-PABind 
STAO 


A-PABind 
STAO 


A-PABind 
STAO 


A-PABind 
STAO 
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AMENDMENT 1 : Authentication during association establishment 



[MOVE THE INTRODUCTION (THE ORIGINAL CLAUSE 01 TO THE 
FRONT OF THE INTERNA TIONAL STANDARD ASA PRELIMINARY 
ELEMENT. WHEN THIS IS DONE. THE INTRODUCTION WILL BE ON 
PAGE *v" AND THE NUMBERS PRECEDING THE PARAGRAPHS 
OF THE ORIGINAL CLA USE WILL BE REMOVED. } 

Introduction 

{ADD THE FOLLOWING SENTENCE TO THE END OF THE THIRD 
PARAGRAPH (I.E., THE ORIGINAL 0. 3). } 

The ACSE protocol also includes an optional functional unit 
for exchanging information to support authentication during 
association establishment. The ACSE services apply to a 
wide range of application-process communication require- 
ments. 

1 Scope ond f i eld of oppl l ootlon 

{INSERT THE FOLLOWING TEXT ASi THE NEW SECOND PARA- 
GRAPH OF CLAUSE 1.) 

The Kernel functional unit is used to establish and release 
application-associations. The Authentication functional unit 
provides additional facilities for exchanging information in 
support of authentication during association establishment 
without adding new services. The ACSE authentication 
facilities can be used to support a limited class of authentica- 
tion methods. 

{MODIFY THE NEW THIRD PARAGRAPH (I.E., THE ORIGINAL 
SECOND PARAGRAPH) AS FOLLOWS. ) 

This International Standard specifies: 

a) procedures for the transfer of information «for» fetet«ft§ 
te application-association control «and the authentication 
of* bot w oon application-entities; and 

b) the abstract syntax for the representation of the ACSE 
APDUs. 



2 ^Normative* references 

{INSERT THE FOLLOWING TEXT AS THE NEW PARAGRAPH 
UNDER CLA USE 2 BEFORE THE LIST OF REFERENCES. ) 

The following standards contain provisions which, through 
reference \n this text, constitute provisions of this Interna- 
tional Standard. At the time of publication, the editions 
indicated were valid. All standards -are subject to revision, 
and parties to agreements based on this International Stand- 
ard are encouraged to investigate the possibility of applying 
the most recent editions of the standards listed below. 
Members of IEC and ISO maintain registers of currently valid 
International Standards. 

{ADD THE FOLLOWING REFERENCES. } 

ISO 6523, Data interchange — Structure for identification of 
organizations. 

ISO 7498-2:1 989, In formation processing systems — Open 
Systems Interconnection — Basic Reference Model — Part 
2: Security architecture. 

ISO/IEC 9545:1989, Information technology - Open Sys- 
tems Interconnection — Application Layer Structure. 

ISO/IEC 9834-1 \ Information technology - Open Systems 
Interconnection — Procedures for the operation of OSI 
registration authorities — Part 1: General procedures. 

ISO/IEC 9834-6 1 , Information technology - Open Systems 
Interconnection — Procedures for the operation of OSI 
registration authorities — Part 6: AP titles andAE titles. 
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3 Definitions 

3.1 Reference model definitions 

3.1.1 Basic reference model definitions {NEW HEADING) 
{MOVE TEXT FROM ORIGINAL 3. 1 TO THIS SUBCLAUSE. ) 
{INSERT NEW SUBCLAUSE 3. 1.2. } 

3.1.2 Security architecture definitions {NEW} 

This International Standard makes use of the following term 
defined in ISO 7496-2: 

password. 

{END OF INSERTED SUBCLAUSE 3. 1.2. } 

3.1.3 Naming and addressing definitions {PREVIOUSLY 3.2} 
{MOVE TEXT FROM ORIGINAL 3.2 TO THIS SUBCLAUSE. } 

3.2 Service conventions definitions {previously 3.3} 

{MOVE TEXT FROM ORIGINAL 3.3 TO THIS SUBCLAUSE. } 

3.3 Presentation service definitions {previously 3.4} 

{MOVE TEXT FROM ORIGINAL 3.4 TO THIS SUBCLAUSE. } 



3.4 ACSE service definitions {previously 3.5} 

{MOVE TEXT FROM ORIGINAL 3.5 TO THIS SUBCLAUSE AND ADD 
THE FOLLOWING DEFINITIONS MAINTAINING ALPHABETICAL 
ORDER.) 

authentication 
authentication-function 
authentication-value 
authentication-mechanism 
[INSERT NEW SUBCLAUSE 3.5.} 

3.5 Application Layer Structure definitions [NEW) 

This International Standard makes use of the following terms 
defined in ISO/IEC 9545: 

s) application-entity invocation; 

b) single association control function; and 

c) single association object. 
[END OF INSERTED SUBCLAUSE 3.5.) 

4 Abbreviations 

[ADD THE FOLLOWING ABBREVIATIONS MAINTAINING AL- 
PHABETICAL ORDER.} 

AEI application-entity invocation 

RPOA recognized private operating agency 

SACF single association control function 

SAO single association object 

[END OF ADDED ABBREVIA TIONS. ) 



5 Conventions [NO change) 

[NO CHANGE IS MADE TO THIS CLAUSE.) 
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6 Overview of the protocol 
6.1 Service provision {no change) 

{NO CHANGS IS MADE TO THiS SUBCLA USE. ) 

{INSERT THE FOLLOWING TEXT AS NEW SUBCLAUSE 6, U BE- 
TWEEN SUBCLAUSES 6. 1 AND 6.2.) 

6.1a Functional units {NEW) 

S.la.l Functional units are used by this International Stand- 
ard to negotiate ACSE user requirements during association 
establishment. Two functional units are defined: 

a) Kernel functional unit; and 

b) Authentication functional unit. 

e.1a.2The ACSE Requirements fields on the AARQ and 
A ARE APDUs are used to select the Authentication function- 
al units for the association. 

e.la.3 The Kernel functional unit is always available. It is the 
default functional unit. To be included, the Authentication 
functional unit shall be explicitly requested on the AARQ 
APDU and accepted on the AARE APDU. 

S.la.4 The selection of the Authentication functional unit 
supports additional fields on the AARQ, AARE, and RLRQ 



APDUs. It does not affect the elements of procedure. Table 
1a shows the services, APDUs and APDU fields associated 
with the ACSE functional units. 

{END Of INSERTED SUBCLAUSE 6. U. INSERT NEW TABLE 1: 
RENUMBER THE TABLES AND ADJUST REFERENCES TO THESE 
TABLES IN THE TEXT.) 

6.2 Use of presentation-service {no change) 

{NO CHANGE IS MADE TO THIS SUBCLAUSE. ) 

6.3 Relationship to session-service {NO change) 

{NO CHANGE IS MADE TO THIS SUBCLA USE. ) 

6.4 Model 

{INSERT THE FOLLOWING ntW NOTE AFTER PARAGRAPH 
6.4.1.) 

NOTE - An ASE standard that references ACSE need not 
specify the use of ACSE service primitive parameters that are 
irrelevant to its operation. The SACF can be modeled to pass 
such parameters between the ACPM and that part of the AEI to 
which the parameters are relevant. 

{ END OF INSERTED NOTE. ) 



Table 1a — Functional unit APDUs and their fields (new 


Functional Unit 


Service 1 IE 


Field Name | 


Kernel 


A-ASSOCIATE 


AARQ 


Protocol Version 
Application Context Name 
Calling AP Title 
Calling AE Qualifier 
Calling AP Invocation-identifier 
Calling AE Invocation-identifier 
Called AP Title 
Called AE Qualifier 
Called AP Invocation-identifier 
Called AE Invocation-identifier 
Implementation Information 
User Information 






AARE 


Protocol Version 
Application Context Name 
Responding AP Title 
Responding AE Qualifier 
Responding AP Invocation-identifier 
Responding AE Invocation-Identifier 
Result 

Result Source • Diagnostic 
Implementation Information 
User Information 




A-RELEASE 


RLRQ 


Reason 

User Information 






RLRE 


Reason 

User Information 




A-AB0RT 


ABRT 


Abort Source 
User Information 


Authentication 


A-ASSOCIATE 


AARQ 


ACSE Requirements 
Authentication-mechanism Ham% 
Authentication-value 
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7 Elements of procedure 

{NO CHANGE 1$ MADS TO THE INTRODUCTORY TEXT. ) 

7.1 Association establishment 

{ TABLE 2 (AARQ APDU FIELDS) - ADD THE FOLLOWING ROWS 
AFTER Catted AE Invocation-identifier AND BEFORE Implementa- 
tion Information.) 



ACSE-requirements 


U 


reqind 


Authentication-mechanism Name 


U 


raqind 


Authentication-value 


U 


reqind 



{ADD THE FOLLOWING NOTE TO TABLE 2. } 

NOTE - The Authentication-mechanism Name and Authentica- 
tion-value fields are only present if the ACSE-requirements field 
includes the Authentication functional unit. 

{ TABLE 3 (AAREAPDU FIELDS) - ADD THE FOLLOWING ROWS 
AFTER Result Source - Diagnostic AND BEFORE Implementation 
Information.} 



ACSE-requirements 


U 


rsp 


cnf 


Authentication-mechanism Name 


U 


rsp 


cnf 


Authentication-value 


U 


rsp 


cnf 



[ADD THE FOLLOWING NOTE TO TABLE 3. } 

NOTE — The Authentication-mechanism Name and Authentica- 
tion-value fields are only present if the ACSE-requirements field 
includes the Authentication functional unit. 

7.1.1 Purpose [no change 

{NO CHANGE IS MADE TO THIS SUBCLA USE. ) 

7.1.2 APDUs used [no changes 

[NO CHANGE IS MADE TO THIS SUBCLA USE. } 

7.1 .3 Association establishment procedure 

{MODIFY PARAGRAPH 7. 1.3.2.4 AS FOLLOWS.) 

7.1.3.2.4 If the P-CONNECT indication primitive and its 
AARQ APDU are acceptable, the ACPM "inspects the ACSE- 
requirements field if it is present. It removes functional units 
that it does not support. The ACPM then issues* an A-AS- 
SOCIATE indication primitive to the acceptor. The A-AS- 
SOCIATE indication primitive parameters are derived from 
the AARQ APDU and the P-CONNECT indication primitive. 
The ACPM waits for a primitive from the acceptor. 

7.1 .4 Use of AARQ APDU fields 

{INSERT NEW SUBCLAUSES 7.1.4.10a, 7.1.4.10b AND 
7. 1.2. 10c AFTER SUBCLAUSE 7. 1. 1. 10 Called AE Invocation- 
identifier.} 

7.1.4.10a ACSE-requirements 

For the requesting ACPM: The value assigned to this field is 
determined by the value of the ACSE Requirements 
parameter of the A-ASSOCfATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the ACSE Requirements parameter of the A-AS- 
SOCIATE indication primitive, if issued. The ACPM inspects 



the ACSE-requifiitnents field end removes any functional 
units not supported by the ACPM before issuing it to the 
service-user. 

7.1 .4.10b Authentication-mechanism Name 
For the requesting ACPM: The value assigned to this field is 
determined by the velue of the Authentication-mechanism 
Name parameter of the A-ASSOCIATE request primitive. 

For the accepting ACPM : This value is used to determine the 
value of the Authentication-mechanism Name parameter of 
the A-ASSOCIATE indication primitive, if issued. 

7 . 1 .4. 1 0c Authentication-value 

For the requesting ACPM: The value assigned to this field is 
determined by the value of the Authentication-value 
parameter of the A-ASSOCIATE request primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Authentication-value parameter of the A-AS- 
SOCIATE indication primitive, if issued. 

{END OF INSERTED SUBCLAUSES 7.1.4.10a. 7.1.4.10b AND 
7.1.4.10c.) 

7.1 .5 Use of AARE APDU fields 

{INSERT NEW SUBCLAUSES 7. 1.5.8a. 7. 1.5.8b AND 7. 1.5.8c 
AFTER SUBCLA USE 7.1.5.8.2 Diagnostic Value. } 

7.1.5.8a ACSE-requirements 

For the accepting ACPM: The value assigned to this field is 
determined by the value of the ACSE Requirements 
parameter of the A-ASSOCIATE response primitive. This 
value shall only include functional units that were on the 
indication primitive. 

For the requesting ACPM: This value is used to determine 
the value of the ACSE Requirements parameter of the A-AS- 
SOCIATE confirm primitive. 

7.1.5.8b Authentication-mechanism Name 

For the accepting ACPM: The value assigned to this field is 
determined by the value of the Authentication-mechanism 
Name parameter of the A-ASSOCIATE response primitive. 

For the requesting ACPM: This value is used to determine 
the value of the Authentication-mechanism Name parameter 
of the A-ASSOCIATE confirm primitive. 

7.1 .5.8c Authentication-value 

For the accepting ACPM: The value assigned to this field is 
determined by the value of the Authentication-value 
parameter of the A-ASSOCIATE response primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Authentication-value parameter of the A-AS- 
SOCIATE confirm primitive. 

{END OF INSERTED SUBCLAUSES 7.1.5.8a. 7.1.5.8b AND 
7.1.5.8c.) 

7.1.6 Collisions and interactions [nochanoe\ 
{NO CHANGE IS MADE TO THIS SUBCLAUSE. ) 
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7.2 Normal release of an association {no change] 

{NO CHANGE IS MADE TO THIS SUBCLA USE. ) 

7.3 Abnormal release of an association {no change) 

7.3.1 Purpose [no chanqq 

{NO CHANGE IS MADE TO THIS SUBCLAUSE. ) 

7.3.2 APDUs used 

{NO CHANGE IS MADE TO THE TEXT IMMEDIATELY UNDER 
7.3.2} 

{ TABLE 6 - ADD THE FOLLOWING ROW AFTER Abort Source 
AND BEFORE User Information. ) 

Diagnostic U req ind 

7.3.3 Abnormal release procedure \no change 
{NO CHANGE IS MADE TO THIS SUBCLA USE ) 



7.3.4 Use of ABRT APOU fields 

{RENUMBER THE ORIGINAL 7.3.4.2 AS 7.3.4.3. INSERT NEW 
SUBCLAUSE 7.3.4.2.) 

7.3.4.2 Diagnostic 

For the requesting ACPM: This value is determined by the 
value of the Diagnostic parameter of the A-ABORT request 
primitive. 

For the accepting ACPM: This value is used to determine the 
value of the Diagnostic parameter of the A-ABORT indication 
primitive. 

{END OF INSERTED SUBCLAUSE 7.3.4.2.) 



8 Mapping to the presentation-service {NO 

CHANGE) 

{NO CHANGE IS MADE TO THIS CLAUSE. ) 
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9 Structure and encoding of ACSE APDUs 

(CLAUSE 9 IS MODIFIED AS INDICATED BELOW.} 

{FOR THE AARQ-epdu PRODUCTION (PAGE 1 7) - INSERT THE FOLLOWING LINE. MAINTAINING TAG ORDER.} 

sender-acse-requirements [10] IMPLICIT ACSE- requirements OPTIONAL. 

-This field shell not be present if only the Kernel is used. 

mechanism-name [11] IMPLICIT Mechanism-name OPTIONAL, 

-This field shell only be present if the Authentication functional 
-unit is selected. 

calling-authentication-value [12] EXPLICIT Authentication-value OPTIONAL. 
-This field shall only be present if the Authentication functional 
-unit Is selected. 



(FOR THE AARE-apdu PRODUCTION (PAGE 17) - INSERT THE FOLLOWING LINE. MAINTAINING TAG ORDER.} 

responder-acse-requi rements [8] IMPLICIT ACSE -requirements OPTIONAL. 

-This field shall not be present if only the Kernel is used. 

mechanism-name [9] IMPLICIT Mechanism-name OPTIONAL. 

-This field shall only be present if the Authentication functional 
-unit is selected. 

responding-authenti cat ion- value [10] EXPLICIT Authentication-value OPTIONAL, 
-This field shall only be present if the Authentication functional 
-unit is selected. 



{FOR THE ABRT-apdu PRODUCTION (PAGE 18) - REPLACE WITH THE FOLLOWING PRODUCTION.) 

ABRT-apdu ::- [ APPLICATION 4 ] IMPLICIT SEQUENCE 
(abort-source [0] IMPLICIT ABRT-source. 

abort-diagnostic [1] IMPLICIT ABRT -diagnostic OPTIONAL. 

-This field shall not be present if only the Kernel is used, 
user-information [30] IMPLICIT Assoc i at ion- information 

} 



{INSERT THE FOLLOWING PRODUCTION AFTER THE ABRT-source PRODUCTION (PAGE 19).} 

ABRT-di agnostic ::• ENUMERATED 
{ no-reason-given (1). 

protocol -error (2). 

authentication-mechanistr-name-not-recognized (3) , 

authentication-mechani sm-name-requi red (4) , 

authentication-failure (5). 

authentication-required (6) 
} 
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(FOR THE Assoclate-source-diagnostic PRODUCTION (PAGE 20) - INSERT THE FOLLOWING LINES AFTER "called-AE-in- 
vocatlon-ld -not -recognized (10)/.} 

authentl cat Ion -mechanism-name -not -recognized (11) , 
•uthentl cat 1 on-mechani sm-name-requ1 red ( 12) , 
authentication-failure (13), 
authentication-required (14) 



(INSERT THE FOLLOWING PRODUCTIONS AFTER THE Association -Information PRODUCTION (PAGE 20).} 

ACSE-requ1 rements : :- BITSTRING 
{ authentication (0) } 

mechanism-name ::- OBJECT IDENTIFIER 

-This field shall be present if authentication -value Is of 
-type ANY DEFINED BY. 

authentication-value ::■ CHOICE 

{ charstring [0] IMPLICIT GrapMcString, 
bitstrlng [1] IMPLICIT BITSTRING. 
external [21 IMPLICIT EXTERNAL, 
other [3] ANY DEFINED BY mechanism- name 

} 

-The abstract syntax of authentication-value is determined 
-by the authentication-mechanism used during association 
-establishment. The authentication-mechanism is either 
-explicitly denoted by the OBJECT IDENTIFIER value 
-for mechanism-name, or it is known implicitly by prior 
-agreement between the communicating partners. 
-If "other" is chosen, then "mechanism-name 11 must 
-be present In accordance with ISO 8824. 
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10 Conformance 

{NO CHANGE TO THE INTRODUCTORY TEXT. ) 

10.1 Statement requirements 

[REPLACE ITEM b) WITH THE FOLLOWING TEXT) 

b) statements about which ACSE functional units are 
implemented; and 

10.2 Static requirements {no change) 

{NO CHANGE IS MADE TO THIS SUBCLA USE. ) 

10.3 Dynamic requirements {no change) 

{NO CHANGE IS MADE TO THIS SUBCLA USE. ) 

11 Precedence [NO CHANGS) 

{NO CHANGE IS MADE TO THIS CLA USE. ) 



{INSERT NEW CLAUSE 12.\ 



12 Registration requirements {NEWS 

This International Standard identifies the requirement to 
register three types of information objects: application titlea; 
application contexts; and authentication-mechanisms. Each 
is discussed below. 

No International Registration Authority ia currently planed for 
the registration of any of the above objects. The assignment 
of a name to any of these objects shall be in accordance with 
the general provisions of ISO/IEC 9834-1, except as 
specified below. 

In accordance with ISO/IEC 9834-1, an organization that 
wishes to assign names to objects shall f ihd an appropriate 
superior of the naming tree. The superior assigns an arc of 
the naming tree to the organization. The organization can 
then assign names below that arc. 

NOTE - Appropriate superiors in the registration tree include 
ISO/IEC national bodies, organizations with International Code 
Designators assigned in accordance with 160 6523, as well ss 
CCITT network administrations, and recognized private operat- 
ing agencies (RPOAs). 

12.1 Application titles 

The application titles requiring registration are application- 
process title, application-entity qualifier, and application-en- 
tity title. The registration requirements for these information 
objects are contained in ISO/IEC 9545, clause 9. ISO/IEC 
9834-6 specifies both the relationship between these infor- 
mation objects and the procedures to register them. 

12.2 Application context 

The registration requirements for an application context is 
contained in ISO/IEC 9545, clause 9. ISO/IEC 9834-1 
specifies the procedures to register it. 

12.3 Authentication -mechanism 

An authentication-mechanism may be specified as part of an 
International Standard. For example, annex B of this Interna- 
tional Standard specifies an authentication-mechanism 
based on AE title and password. Such an authentication- 
mechanism is, in effect, specified and registered within the 
International Standard. 

An authentication-mechanism may also be specified outside 
of International Standards. In this situation, ISO/IEC 9834-1 
specifies the procedures to register such an authentication- 
mechanism. 

{£A J OF INSERTED CLAUSE 12. ) 
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Annex A 

(normative) 
ACPM state table 



{NO CHANGE IS MADE TO THE TECHNICAL CONTENT OF THE 
ACPM STA TE TABLE. HOWEVER, TO CONFORM TO ISO EDITING 
CONVENTIONS, RENUMBER TABLES 10, 11, 12, 13 AND MAS 
A. 1, A. 2, A. 3, A. 4, AND A. 5. MAKE THE APPROPR/A TE CROSS- 
REFERENCE CHANGES IN ANNEX A. } 



{INSERT NEW ANNEX B, STARTING ON THE NEXT PAGE.) 
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Annex B {NEW} 

(normative) 

Authentication-mechanism using password 



B.O Introduction 

This annex specifies a simple authentication-mechanism 
that uses a password with an AE title. This authentication- 
mechanism is intended for general use. It is also an example 
of an authentication-mechanism specification. 

B.1 Assigned name 

The following name (of ASN.1 datatype OBJECT IDEN- 
TIFIER) is assigned to this authentication-mechanism: 



( 



} 



joint-i$o-ccitt 
association-control (2) 
authentication-trechanism(3) 
password- 1(1) 



B.2 Authentication-value ASN.1 datatype 

For this authentication-mechanism, the password is 



the 



authentication-value. The data type of authentication-value 
shall be "GraphicString" in accordance with the production 
for "authentication- value" in clause 9. 



B.3 Processing specification 

In this annex, the term "sending" denotes the AEI (or its 
authentication-function) requesting authentication by its 
peer. The term "receiving" denotes the AEI (or its authen- 
tication-function) performing authentication of its peer. 

B.3.1 Requesting authentication 

B.3.1.1 The sending authentication-function retrieves a 
password value from stored data for its AEI to be cor- 
roborated by the receiving AEI. The password value is 
mapped to the datatype of the authentication-value defined 
in clause B.2. 

B.3. 1.2 When the A-ASSOCIATE request or response primi- 
tive is issued by the sending AEI, the Authentication-value 
parameter shall contain this value. The primitive shall also 
contain the appropriate AP title and AE qualifier parameters 
that indicates its AE title. 

B.3. 1.3 Depending on prior agreements between the sending 
and the receiving AE, the authentication-mechanism name 



(defined in clause B. 1 ) may or may not be included on the 
A-ASSOCIATE primitive. 

B.3.2 Performing authentication 

B.3. 2.1 The receiving authentication-function receives the 
Authentication-value parameter value on the incoming A- 
ASSOCIATE indication or confirm primitive. 

B.3. 2.2 Depending on prior agreements between the sending 
and the receiving AE, the authentication-mechanism name 
(defined in clause B.1) may or may not be included on the 
A-ASSOCIATE primitive. 

B.3. 2. 3 If an authentication-mechanism name is required but 
not received, the authentication-function indicates that an 
A-ABORT request primitive shall be issued. The Diagnostic 
parameter value shall indicate "authentication-mechanism 
name required." 

B.3. 2.4 If an authentication-mechanism name is included, it 
shall be semantically equivalent to that specified in clause 
B.1. If this authentication-mechanism name is not correct, 
the authentication-function indicates that an A-ABORT re- 
quest primitive shall be issued. The Diagnostic parameter 
value shall indicate "authentication-mechanism name not 
recognized." 

B.3.2. 5 The authentication-function then determines if this 
authentication-mechanism (i.e., the authentication- 
mechanism defined in this annex) is allowed for the sending 
AEI based on the AE title of the sending AEI. If this authen- 
tication-mechanism is not allowed, the authentication-func- 
tion indicates that an A-ABORT request primitive shall be 
issued. The Diagnostic parameter value shall indicate 
"authentication failure." 

B.3.2. 6 If this authentication-mechanism is allowed for the 
sending AEI, the authentication-function compares the value 
of the Authentication-value parameter against its stored 
data for this mechanism based on the sender's AE title. If the 
two are semantically equivalent, the authentication-function 
shall indicate successful authentication. 

B.3.2. 7 If the two values are not semantically equivalent, the 
authentication-function indicates that an A-ABORT request 
primitive shall be issued. The diagnostic parameter value 
shall indicate "authentication failure." 



1 ) The implementation of the authentication-mechanism specified in this annex is not required for conformance to this International I 
Standard. However, if employed, the entire specification is binding for the authentication-functions in both AEIs. [ 
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